Seamless Transitions: Unlocking Workstation Migration with Identity Migration Service (IMS)
Workstation Migration with IMS IMS offers workstation migration as part of the solution for migrating user accounts across domains. This service includes joining the machine to the target domain and translating your user profile on the workstation to the target domain. Tool Leveraged for Migration: IMS uses WMT (Workstation Migration Tool) service for performing the workstation migrations across the domains. The Workstation Migration Tool (WMT) Service is specifically designed to perform privileged workstation migration operations. Prerequisites for a Workstation Migration For a workstation to qualify for migration, The WMT Service must be installed and active on the system. This ensures that all migration tasks are executed securely and efficiently. Computers objects must be pre-created by the synchronization service in order to migrate the user's computers. If they do not exist in the target, the migration will fail on the computer migration component. Scope Only enabled computers with a Windows client operating system, Windows 10 or greater, will be synchronized. All non-windows computers (such as Macs) and server computers will not be synchronized. IMS cannot be used to migrate servers and cannot migrate non-Windows clients. How WMT Migrates a Machine's User Profiles When one or more local User Profiles are in scope for migration from the source account ownership to the corresponding target account, they go through the following processing: User profile in scope: Typically, the initial ownership of a user profile (the NTUSER.DAT file) belongs to the user's source domain account. There is a specialization that can be configured to restrict migrating only those user profiles where their corresponding accounts are already migrated. There is a specialization that can be configured to allow a secondary (non-primary) source account to migrate its profile to the corresponding target account. User profile migration process: After rebooting, user account profile migrations are initiated. The size of the user profile will determine how much time is allocated to the user profile change ownership processing (which includes retries). The larger profiles will be allocated more time to process them. When a user profile ownership operation fails, it will not immediately retry; instead, the next profile on the list gets its chance to process first. The retries will be attempted in the subsequent processing cycle. Key Features WMT can track the per user profile translation and not translate the source account's user profile again if it's already translated. Migration Over VPN: By default, support for self-service migration under the VPN mode using the IMS Portal Click Once user interface is enabled. When a user is under VPN mode, only the self-service Portal migration is allowed since the logged in migrating user can be prompted to cache his/her target user account so that he/she can log back in after reboot and before the VPN connection is established. (surrogate Portal migration or the unattended Auto Migration App can't prompt the appropriate user to cache the target account which preventing the user from logging back in and therefore these two migration types should be blocked under VPN). Learn more about IMS Migration methods Migration Over VPN Without Target Domain Join: The WMT Package can be configured to skip joining the client machine to the target domain when migrating the machine over VPN. Under this mode, the target account is still validated and prompted to be cached so that after machine reboots the user can log back in with the migrated target account. WMT App Reregistration Processing and Progress UI: The WMT full-screen splash screen app is used for app reregistration progress UI and informing the user to log back in later due to the user profile change ownership task having not completed yet. The WMT Service has the option to run custom PowerShell external scripts at the following points in the WMT Service workflow. Pre-Workstation Migration (Local System Context) Post-Workstation Migration (Local System Context) After Reboot, After User Profile Migration (Local System Context) After Reboot, After Each User Login, After App Re-registration (Current User Context) IMPORTANT Note: The customer is responsible for maintaining the external script and monitor its logging. IMS only reports successful or unsuccessful execution. Benefits of Workstation Migration Tool: User Profile Tracking: WMT can track per user profile translation and ensure that the source account's user profile is not translated again if it's already translated. Migration Over VPN: The WMT package can be configured to migrate the machine over VPN and also can be configured to skip joining the client machine to the target domain when migrating over VPN, allowing for seamless migration with and without domain join. App Reregistration: The WMT full-screen splash screen app provides a progress UI for app reregistration and informs the user to log back in later due to the user profile change ownership task. Preventing Extra Profiles: A login GPO can use a script to prevent a migrated source account from logging onto a machine where its profile is already migrated to the target account, preventing extra blank profiles. Custom Scripting: The WMT Service allows for custom PowerShell external scripts to be run at various points in the WMT Service workflow, providing flexibility and customization. - Reference blog Custom Scripting Conclusion The Identity Migration Service (IMS) and its Workstation Migration Tool (WMT) offer a robust and efficient solution for migrating user profiles and workstations across domains. Overall, IMS and WMT provide a comprehensive approach to workstation migration, enhancing the digital presence and customer engagement for organizations. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Exploring the Use Cases of ADMS Application Pipeline
A Comprehensive Overview: An Insight into Active Directory Migration Services Application Pipeline. Introduction ADMS, ADSS, and ADGMS are all cloud-based services that come within the ADxS services portfolio offered by Microsoft and designed to facilitate efficient and cost-effective migrations. For additional information around migration use cases, refer to this blog: https://techcommunity.microsoft.com/blog/microsoft-security-blog/exploring-the-use-cases-of-adxs-services/4373299?previewMessage=true . In this blog, we will examine the various use cases of ADMS application pipeline, highlighting its key features and advantages. ADMS or Active Directory Migration Service – is a service designed to facilitate the migration of users and workstations across domains and forests by offering diverse number of migration methods such as Self-Service Migration which is unique to the ADMS service and it comes with two types, Self-Service for corporate connect users, and Self-Service for Remote of VPN users, Admin automated Migrations, user only migration and Migration for workstations shared by more than one user. ADMS Queuing Framework The ADMS user migration is accomplished by several backend processes in addition to the ADMS Portal, which provides a self-service user interface, does pre-validation checking and ensures that the user is approved to migrate. The ADMS solution is scalable to support many concurrent user migrations submitted using the Self-service Portal and by the bulk account submission tool. An ADMS user migration spans across several processes in a workflow. These migration processes are tracked by several persisted work items across several queues. There are four primary types of queues in the ADMS solution for queuing up and serving work items. These work items are processed on a first-in-first-out (FIFO) basis where interactive migrations using the Self-service/Surrogate Portal have a higher priority than ones submitted in bulk with the Auto Migration app or the Bulk Account Submission tool. Each ADMS work item carries information to enable migration and application remediation features in our solution. This blog will focus on the application remediation (AR) work items. Each user account migrated through the ADMS Migration Portal will be submitted to the app remediation pipeline. When a task appears in the queue destined for that agent, the agent retrieves the task and performs the actions that the agent is configured to perform. This is done per user at migration run-time. ADMS approach for Application and/or Service Remediation during migration. The objective of this blog is to ensure you have a clear understanding of how ADMS delivery approaches application and/or service remediation during migrations. At a high level, we know that there are applications and services that will have some issue when a user migrates from one domain to another. We suggest identifying each application and service and then figuring out whether they will need to be remediated by performing configuration change, a code update, database update, or via an ADMS application remediation (AR) agent. The ADMS delivery team provides a sample application/service catalog where we suggest documenting application and service remediation details along your migration journey and continuing to do so as migrations complete. Migration teams utilize this sample that becomes a living document along the migration journey and a hands off to operational teams post migrations leads to long-term success. Application and service remediation philosophy during ADMS migrations are about coexistence. The user identities that migrate from source to target domain must maintain access across their migration journey and coexistence is key during the migration process focusing on lifting and shifting applications and services downstream allows more runway for operational teams. Coexistence allows primary focus to be on user and device identity management during migrations while allowing a foundation that will support pivoting to rationalizing and upgrading application and service operations downstream from migrations. The ADMS sync engine enables downstream ADMS features to consume identities based on logic provided by our customers early on in our process allowing a mapping for coexistence. Once ADMS sync engine is enabled and running, ADMS delivery team performs our smoke testing, where we validate if our solution meets our agreed upon blueprint for your solution. Once testing is completed, we hand over our solution to the customer migration teams to perform their own UAT. The key to customer migration success around applications and services remediations is getting started early testing with early adopters. We suggest our customers use identities that mirror their migration use cases prior to getting into production identities to validate remediation tasks during the migration journey. The next phase would be to ramp up into a larger pilot, where most customers use technology friendly business units to perform deeper dive remediation testing use cases. ADMS migration is non-destructive to the source user identity. We are not touching or altering any accounts in the source so customers can start with a pilot knowing that we have not done anything to unravel the source account, maintaining coexistence. Customers can migrate a test account forward and confidently know that the source account remains intact while you are testing with the migrated target domain identity. ADxS in Action: Practical Approaches to Application Remediation The ADMS delivery team suggest classifying applications and services into categories or “buckets” to help identify remediation types and timings during your migration journey. Let’s discuss those in more detail from a typical ADMS delivery: ADMS Runtime: This category would be where ADMS can help the most during migrations. There are per instance fees for each ADMS AR instance so typically limited to a few configuration items. As an example, a proprietary database update is needed at the time a user is migrating, ADMS updates the reference to the source and changes it to the target identity for that migration user or bulk or migration users. An example would be calling an existing stored procedure to update a custom application/service in the customer environment. Static Change: This category would be where customer migration teams need to make a one-time application or service change. These types of changes usually need a change control, scheduled change per application/service. An example of this use case would be an LDAP application only putting to the source domain/realm and needs an update to include the target domain/realm. Dual ID: As mentioned, we do not do anything destructive to the source account so you can pivot back to that identity and retain the existing access obtained while in the source domain. Out-of-Band: The last category would be applications and/or services that can be decoupled from user migration. Once we have user identities synced, we can work with customer migration teams to provide an identity mapping file that can assist in security translations to remediate the out-of-band processes where appropriate. The key objective from our perspective to building out an application/service catalog as it relates to coexisting during migration is putting these “buckets” in place. They help migration teams sort the entire application/service portfolio so as everyone goes through their test use cases and someone says “hey, this app/service doesn’t work”, your team can ask, “ok, WHY doesn’t it work?” and it typically falls into one of those categories or “buckets” listed above. They help migration teams to define what needs to be done to correct the issue and allow coexistence during your migration journey. The Ultimate ADxS Guide: Application Remediation for Modern Migrations The ADMS delivery team has seen these common types of application and service dependencies most frequently during ADMS migrations. Let’s discuss those in more detail from a typical ADMS delivery: AD Security Group Membership: As part of the ADMS sync engine, we have the ability to sync source groups to the target environment based on an agreed upon mapping of group objects. ADMS has a feature we can enable that will bring over SIDHistory for in scope groups that are part of the ADMS sync process. This resolves many of the AD-dependent application/service access scenarios where SIDHistory is honored by that application/service. AD Attributes: Exchange is an example of where we can pick up attributes in the source and flow them to the target. Some applications/services require an attribute for authorization and in those cases, you’ll want to identify requirements and include them in the ADMS sync engine configuration. Proprietary Database: Some applications/services have a proprietary database that needs to update when the user migrates to the target. SharePoint is a good example of this use case, where we must reach out to the database, and update that reference from the source identity to the target identity at user migration run-time. LDAP Application - Best case scenario, the LDAP application is capable of binding to multiple realms, meaning it can connect to multiple Active Directory domains that are in scope for user and device migrations. Customer teams can remediate the application by configuring the application to bind to the target domain, which is the landing zone for migration. If however, you have an application that is only single-realm bind capable there are a couple options: -- Migrate all users in scope for this single-realm bind use case in a single migration batch then change the application to point to the target domain post user migration. -- Another possibility is changing authentication to use local accounts during the migration, then point the application back to target domain authentication post user migration. -- A third option is to check with the application owner to determine if an update is available to the application to allow multi-realm bind use case. -- The last resort option would be to leave the source account enabled to allow existing access while your team works on a long-term solution. Cloud Identity - There are some applications and services that rely on a cloud Identity to allow access. Your source of authority that determines source vs target Identity will come into play for this use case. Customer may need to review and update their sync to cloud configuration to allow coexistence for this use case as the user and device migrates to the target domain. How can ADMS help? The ADMS delivery team can handle at run-time remediation in the ADMS AR pipeline. This is done per user at user migration run-time to allow coexistence, maintaining access for those pending migration, and updating access for those that have performed migration throught the ADMS Portal. Customer teams will need to identify any changes that need to be made within the organization to allow coexistence per application/service. A critical role during ADMS migration is the customer UAT role. During workshops, we enable this role to assist in building out the customer application/service catalog as well as the migration test plans. Migration success relies on this role in regards to customer application/service remediation. As migrations end, customers can use this catalog as a living document that is a key factor in long-term operational success. With this guide in hand, customers know what it takes to allow and disallow access to every application/service in the organization so their provisioning and deprovisioning process is better than it ever has been based on the efforts put in during their ADMS migrations. Conclusion ADMS AR pipeline offers endless extensibility options during user migrations by allowing customers to execute remediation at time of user migration. This feature has been priceless in recent migrations to allow customers to execute downstream workflow assisting their migration journey goals end to end. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Blog Series: Charting Your Path to Cyber Resiliency
Cyber resiliency is an organization’s ability to build and manage technology systems that limit the impact of cyberattacks. It helps organizations maintain operations, securely and effectively, when cyberattacks occur. As Microsoft notes, “An organization can never have perfect security, but it can become resilient to security attacks.” In Part 1 of this series, we looked at how the concept of cyber resiliency originated, introduced 2 foundational cyber resiliency frameworks and wrapped up with a quick look at some Microsoft cyber resiliency resources from our 2022 Digital Defense Report. In Part 2, we’ll dive deeper into Microsoft’s approach to cyber resiliency, starting back in 2002 with the famous Trustworthy Computing memo from Bill Gates himself. TrustWorthy Computing In 2002, Microsoft founder and CEO Bill Gates emailed a memo to all Microsoft employees, outlining the need for a new approach to how the company provided security and resiliency to our customers, and calling for changes to Microsoft products and culture. Gates referenced September 11 and several serious malware incidents in 2001 that had caused significant business disruptions, emphasizing "how important it is to ensure the integrity and security of our critical infrastructure, whether it’s the airlines or computer systems." Gates also foresaw how increasingly connected and dependent on the Internet the world would become in the future – a concept that played a key role in the development of cyber resilience frameworks. The Trustworthy Computing initiative was not created specifically to address cyber resiliency, but like cyber resiliency it was holistic in its treatment of security, covering diverse areas such as software development and customer support, as well as Microsoft’s internal operational and business practices. A 2014 article by Forbes praised Microsoft for the impact of Trustworthy Computing on Security, not just for Microsoft products, but for the entire IT industry, noting "We’ve come a long way from the 'Wild West” era of malware—thanks in large part to the ongoing efforts of Microsoft Trustworthy Computing." Zero Trust Microsoft didn't invent Zero Trust but has been an industry leader in actively promoting and developing Zero Trust strategies for many years, as well as using Zero Trust to secure our own environments. For example, Microsoft has collaborated with NIST (the National Institute of Standards and Technology) and other vendors to develop a practice guide to help organizations design and build Zero Trust architectures. Zero Trust and cyber resiliency are not the same, but there are many similarities between them, starting with the idea that we must Assume Breach, given the speed, scale and sophistication of threat actors and the challenges every Security team faces. In addition: Both stress the importance of identifying the most critical business resources and prioritizing the protection of those resources Both are concerned with limiting the blast radius of an attack and reducing the attacker’s ability to move laterally Both are designed to protect hybrid environments across multiple pillars that include both legacy and modern technologies Both emphasize the need for the organization to continually adapt protections to keep up with threat actors Secure Future Initiative There are many similarities between the TrustWorthy Computing initiative and Microsoft’s current Secure Future Initiative (SFI). Again, it began with an internal memo to employees, this time by Microsoft Security EVP Charlie Bell, in November 2023. Like TrustWorthy Computing, SFI illustrates Microsoft’s leadership in addressing current cybersecurity challenges that now include AI advancements, increasingly sophisticated ransomware-as-a-service organizations, and nation-state activity targeting critical infrastructure. Like TrustWorthy Computing, SFI is holistic in nature. As Vice Chair and President Brad Smith emphasized in his own intro to SFI "This new initiative will bring together every part of Microsoft to advance cybersecurity protection." The Secure Future Initiative is also rooted in Microsoft’s experiences as a company dedicated to continually improving our own cyber resilience. In a May 2024 report on SFI progress, Microsoft CEO Satya Nadella noted that cyberattacks, such as the 2023 Storm-0558 attack that targeted Microsoft, 'underscore the severity of the threats facing our company and our customers, as well as our responsibility to defend against these increasingly sophisticated threat actors." Finally, like TrustWorthy Computing, SFI is clear that security – both for Microsoft and for our customers – is the company’s number one priority. Satya concluded his message with a familiar call to action for Microsoft employees: "If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security." Microsoft's Key Issues Impacting Cyber Resiliency Part 1 of this series introduced Microsoft’s key issues impacting cyber resiliency. These are issues that we in MIRCAT (the Microsoft Incident Response Critical Action Team) routinely address in our incident response/compromise recovery work with clients: Insecure configuration of identity provider Insufficient privilege access and lateral movement controls No Multi-Factor Authentication Low maturity security operations Lack of information protection control Limited adoption of modern security frameworks Each of these issues is further broken down into distinct components. For example, the issue Insufficient privilege access and lateral movement controls has 5 components: No privilege isolation in Active Directory via tier model No use of Privilege Access Workstations Lack of local admin password management controls Lack of Privilege Access Management controls Excessive admin credentials found Trying to address all cyber resilience issues can be overwhelming for clients, which is why we emphasize taking a phased approach to each issue and component. For example, Lack of Privilege Access Management controls in Entra can be addressed by Microsoft Privileged Identity Management (PIM). When helping a client implement PIM, we employ a phased approach that might look something like this: Phase 1: Implement PIM to protect privileged roles in Entra, starting with Global Administrators and guest accounts. Gradually onboard additional Entra Admin roles. Phase 2: Implement PIM to protect select highly privileged roles in the most business-critical Azure subscriptions. Gradually onboard additional subscriptions. Phase 3: Extend PIM management to more complex use cases involving time-bound privileged group membership, authentication context and approval workflows. When implementing a security technology to help your organization increase cyber resiliency, your goal should be to implement it fully with no exceptions. Unfortunately, in incident response and compromise recovery engagements we often see gaps that limit our clients’ resilience to cyberattacks. For example, we regularly work with clients who tell us that they’ve implemented PIM, only to find that many privileged roles have been permanently assigned outside of PIM. In other cases, we see PIM used only for Entra roles while no privileged access controls are applied to Azure subscriptions running business-critical workloads. At the same time, when business reasons dictate that a cyber resilience control cannot be fully implemented, organizations should not adopt an all-or-nothing approach. For example, financial constraints prohibit some clients from providing privileged access workstations to all administrators or FIDO 2 compatible security keys to all users. In those cases, organizations are encouraged to start by providing those additional protections to Tier 0 administrators at a minimum, followed by Tier 1 administrators of business-critical workloads. Conclusion In Part 2 of our series, we explored how Microsoft has been an industry leader in cyber resiliency over the years, beginning with the days of TrustWorthy Computing more than 20 years ago. We also delved deeper into Microsoft’s current guidance on the key issues that we see limiting our customers’ cyber resilience. The journey to cyber resilience is a challenging and time-consuming one with a lot of Big Rocks that clients commonly struggle with: Vulnerability management Policy management Securing privileged access Adapting to the continuously changing cyber threat landscape Maturing the SecOps capability Fortunately, it’s a journey that organizations don’t have to make alone, and increasingly it’s a journey that AI can help with. And that’s what we’ll examine in the final part of this series.Exploring the Extensibility of Active Directory Migration Service (ADMS) Device Migration
Introduction Active directory migrations are a critical journey and a key success factor in your identity architecture for the future of your organization. Our portfolio offers services to assist your migration teams in various migration use cases, including acquisition, merger, divestiture, directory consolidation, and cloud enablement. Have you ever tried to migrate a device from one Active Directory environment to another? This is not an easy task especially when you try to scale your migration solution. Let us take you on our device migration journey. Overview of ADxS Services Active Directory Migration Service (ADMS), Active Directory Synchronization Service (ADSS), and Active Directory Group Modernization Service (ADGMS) are cloud-based services within the ADxS services portfolio offered by Microsoft. These services are designed to facilitate efficient and cost-effective migrations. In this article, we will examine the various extensibility options of ADMS WMT Service, highlighting its key features and advantages. Device Migration with ADMS Conventional tools require mapping of users to workstations so that the migration sequence can be structured and run by the migration team. ADMS offers a simple to use portal service so that self-service migrations can be offered with users now able to migrate when it's convenient for them. The ADMS device migration is accomplished by the Workstation Migration Tool (WMT), which uses a service for conducting workstation migration operations. The WMT Service is required for a workstation to be eligible for migration. If the WMT Service is not preinstalled before migration, the portal's WMT Service prerequisite check will fail, and the migration will not proceed any further. ADMS WMT service performs at device migration runtime when invoked by ADMS Portal or our auto migration app to perform our default migration operations as well as any additional features we agreed upon during our design discussions for your ADMS delivery. ADMS WMT service allows the extensibility to run custom external scripts at various execution points during the device migration sub steps, which has been a game changer for our ADMS customers. WMT Service running custom external scripts The WMT Service has the option to run custom PowerShell external scripts at the following points in the WMT Service workflow: Pre-Workstation Migration: This location of workflow executes prior to the device being domain join to the target domain. This is the first activity after the user mappings are obtained for WMT migration sub steps. Context is Local System. Post-Workstation Migration: This location of workflow executes after the device is domain join to the target domain but prior to the reboot of the device. This is the last activity before the device reboots post domain join. Context is Local System. After Reboot, After User Profile Ownership Change: This location of workflow executes after device domain join to the target domain, post reboot, and after all user profiles change their ownership from the source account to the target account. The goal of this script should be to complete it in a timely manner before any user logs back on to the device with their target account. Context is Local System. After Reboot, After Each User Login, After App Re-registration: This location of workflow executes after device domain join to the target domain, post reboot, and after the user’s app registration completes. This is performed for each user logging back in with their target account executing prior to their Windows desktop being available. Context is logged in user context. Partnership in device migration customization ADMS team can enable these WMT Service execution workflows very quickly after agreeing with customer migration teams on name and location of custom scripts that will reside on the devices during their migration journey. These custom scripts must be deployed by the ADMS customer in advance of the device migration and will execute from the agreed upon location during the agreed upon execution time. Customers have used this feature during device migration to perform many real-world case studies that can illustrate the impact of these custom external script. The most common as of late has been in partnership with our customers to assist in their Hybrid Azure Directory Join (HAADJ) migration use case. Stay tuned for future blogs that share some of those use cases during customer migration journeys. Conclusion ADMS WMT Service offers endless extensibility options during device migrations by allowing customers to execute custom code at time of device migration performed at various times and contexts. This feature has been priceless in recent migrations to allow customers to execute downstream workflow assisting their migration journey goals end to end. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Enhance AI security and governance across multi-model and multi-cloud environments
Generative AI adoption is accelerating, with AI transformation happening in real-time across various industries. This rapid adoption is reshaping how organizations operate and innovate, but it also introduces new challenges that require careful attention. At Ignite last fall, we announced several new capabilities to help organizations secure their AI transformation. These capabilities were designed to address top customer priorities such as preventing data oversharing, safeguarding custom AI, and preparing for emerging AI regulations. Organizations like Cummins, KPMG, and Mia Labs have leveraged these capabilities to confidently strengthen their AI security and governance efforts. However, despite these advancements, challenges persist. One major concern is the rise of shadow AI—applications used without IT or security oversight. In fact, 78% of AI users report bringing their own AI tools, such as ChatGPT and DeepSeek, into the workplace 1 . Additionally, new threats, like indirect prompt injection attacks, are emerging, with 77% of organizations expressing concerns and 11% of organizations identifying them as a critical risk 2 . To address these challenges, we are excited to announce new features and capabilities that help customers do the following: Prevent risky access and data leakage in shadow AI with granular access controls and inline data security capabilities Manage AI security posture across multi-cloud and multi-model environments Detect and respond to new AI threats, such as indirect prompt injections and wallet abuse Secure and govern data in Microsoft 365 Copilot and beyond In this blog, we’ll explore these announcements and demonstrate how they help organizations navigate AI adoption with confidence, mitigating risks, and unlocking AI’s full potential on their transformation journey. Prevent risky access and data leakage in shadow AI With the rapid rise of generative AI, organizations are increasingly encountering unauthorized employee use of AI applications without IT or security team approval. This unsanctioned and unprotected usage has given rise to “shadow AI,” significantly heightening the risk of sensitive data exposure. Today, we are introducing a set of access and data security controls designed to support a defense-in-depth strategy, helping you mitigate risks and prevent data leakage in third-party AI applications. Real-time access controls to shadow AI The first line of defense against security risks in AI applications is controlling access. While security teams can use endpoint controls to block access for all users across the organization, this approach is often too restrictive and impractical. Instead, they need more granular controls at the user level to manage access to SaaS-based AI applications. Today we are announcing the general availability of the AI web category filter in Microsoft Entra Internet Access to help enforce access controls that govern which users and groups have access to different AI applications. Internet Access deep integration with Microsoft Entra ID extends Conditional Access to any AI application, enabling organizations to apply AI access policies with granularity. By using Conditional Access as the policy control engine, organizations can enforce policies based on user roles, locations, device compliance, user risk levels, and other conditions, ensuring secure and adaptive access to AI applications. For example, with Internet Access, organizations can allow your strategy team to experiment with all or most consumer AI apps while blocking those apps for highly privileged roles, such as accounts payable or IT infrastructure admins. For even greater security, organizations can further restrict access to all AI applications if Microsoft Entra detects elevated identity risk. Inline discovery and protection of sensitive data Once users gain access to sanctioned AI applications, security teams still need to ensure that sensitive data isn’t shared with those applications. Microsoft Purview provides data security capabilities to prevent users from sending sensitive data to AI applications. Today, we are announcing enhanced Purview data security capabilities for the browser available in preview in the coming weeks. The new inline discovery & protection controls within Microsoft Edge for Business detect and block sensitive data from being sent to AI apps in real-time, even if typed directly. This prevents sensitive data leaks as users interact with consumer AI applications, starting with ChatGPT, Google Gemini, and DeepSeek. For example, if an employee attempts to type sensitive details about an upcoming merger or acquisition into Google Gemini to generate a written summary, the new inline protection controls in Microsoft Purview will block the prompt from being submitted, effectively blocking the potential leaks of confidential data to an unsanctioned AI app. This augments existing DLP controls for Edge for Business, including protections that prevent file uploads and the pasting of sensitive content into AI applications. Since inline protection is built natively into Edge for Business, newly deployed policies automatically take effect in the browser even if endpoint DLP is not deployed to the device. : Inline DLP in Edge for Business prevents sensitive data from being submitted to consumer AI applications like Google Gemini by blocking the action. The new inline protection controls are integrated with Adaptive Protection to dynamically enforce different levels of DLP policies based on the risk level of the user interacting with the AI application. For example, admins can block low-risk users from submitting prompts containing the highest-sensitivity classifiers for their organization, such as M&A-related data or intellectual property, while blocking prompts containing any sensitive information type (SIT) for elevated-risk users. Learn more about inline discovery & protection in the Edge for Business browser in this blog. In addition to the new capabilities within Edge for Business, today we are also introducing Purview data security capabilities for the network layer available in preview starting in early May. Enabled through integrations with Netskope and iboss to start, organizations will be able to extend inline discovery of sensitive data to interactions between managed devices and untrusted AI sites. By integrating Purview DLP with their SASE solution (e.g. Netskope and iBoss), data security admins can gain visibility into the use of sensitive data on the network as users interact with AI applications. These interactions can originate from desktop applications such as the ChatGPT desktop app or Microsoft Word with a ChatGPT plugin installed, or non-Microsoft browsers such as Opera and Brave that are accessing AI sites. Using Purview Data Security Posture Management (DSPM) for AI, admins will also have visibility into how these interactions contribute to organizational risk and can take action through DSPM for AI policy recommendations. For example, if there is a high volume of prompts containing sensitive data sent to ChatGPT, DSPM for AI will detect and recommend a new DLP policy to help mitigate this risk. Learn more about inline discovery for the network, including Purview integrations with Netskope and iBoss, in this blog. Manage AI security posture across multi-cloud and multi-model environments In today’s rapidly evolving AI landscape, developers frequently leverage multiple cloud providers to optimize cost, performance, and availability. Different AI models excel at various tasks, leading developers to deploy models from various providers for different use cases. Consequently, managing security posture across multi-cloud and multi-model environments has become essential. Today, Microsoft Defender for Cloud supports deployed AI workloads across Azure OpenAI Service, Azure Machine Learning, and Amazon Bedrock. To further enhance our security coverage, we are expanding AI Security Posture Management (AI-SPM) in Defender for Cloud to improve compatibility with additional cloud service providers and models. This includes: Support for Google Vertex AI models Enhanced support for Azure AI Foundry model catalog and custom models With this expansion, AI-SPM in Defender for Cloud will now offer the discovery of the AI inventory and vulnerabilities, attack path analysis, and recommended actions to address risks in Google VertexAI workloads. Additionally, it will support all models in Azure AI Foundry model catalog, including Meta Llama, Mistral, DeepSeek, as well as custom models. This expansion ensures a consistent and unified approach to managing AI security risks across multi-model and multi-cloud environments. Support for Google Vertex AI models will be available in public preview starting May 1, while support for Azure AI Foundry model catalog and custom models is generally available today. Learn More. 2: Microsoft Defender for Cloud detects an attack path to a DeepSeek R1 workload. In addition, Defender for Cloud will also offer a new data and AI security dashboard. Security teams will have access to an intuitive overview of their datastores and AI services across their multi-cloud environment, top recommendations, and critical attack paths to prioritize and accelerate remediation. The dashboard will be generally available on May 1. The new data & AI security dashboard in Microsoft Defender for Cloud provides a comprehensive overview of your data and AI security posture. These new capabilities reflect Microsoft’s commitment to helping organizations address the most critical security challenges in managing AI security posture in their heterogeneous environments. Detect and respond to new AI threats Organizations are integrating generative AI into their workflows and facing new security risks unique to AI. Detecting and responding to these evolving threats is critical to maintaining a secure AI environment. The Open Web Application Security Project (OWASP) provides a trusted framework for identifying and mitigating such vulnerabilities, such as prompt injection and sensitive information disclosure. Today, we are announcing Threat protection for AI services, a new capability that enhances threat protection in Defender for Cloud, enabling organizations to secure custom AI applications by detecting and responding to emerging AI threats more effectively. Building on the OWASP Top 10 risks for LLM applications, this capability addresses those critical vulnerabilities highlighted on the top 10 list, such as prompt injections and sensitive information disclosure. Threat protection for AI services helps organizations identify and mitigate threats to their custom AI applications using anomaly detection and AI-powered insights. With this announcement, Defender for Cloud will now extend its threat protection for AI workloads, providing a rich suite of new and enriched detections for Azure OpenAI Service and models in the Azure AI Foundry model catalog. New detections include direct and indirect prompt injections, novel attack techniques like ASCII smuggling, malicious URL in user prompts and AI responses, wallet abuse, suspicious access to AI resources, and more. Security teams can leverage evidence-based security alerts to enhance investigation and response actions through integration with Microsoft Defender XDR. For example, in Microsoft Defender XDR, a SOC analyst can detect and respond to a wallet abuse attack, where an attacker exploits an AI system to overload resources and increase costs. The analyst gains detailed visibility into the attack, including the affected application, user-entered prompts, IP address, and other suspicious activities performed by the bad actor. With this information, the SOC analyst can take action and block the attacker from accessing the AI application, preventing further risks. This capability will be generally available on May 1. Learn More. : Security teams can investigate new detections of AI threats in Defender XDR. Secure and govern data in Microsoft 365 Copilot and beyond Data oversharing and non-compliant AI use are significant concerns when it comes to securing and governing data in Microsoft Copilots. Today, we are announcing new data security and compliance capabilities. New data oversharing insights for unclassified data available in Microsoft Purview DSPM for AI: Today, we are announcing the public preview of on-demand classification for SharePoint and OneDrive. This new capability gives data security admins visibility into unclassified data stored in SharePoint and OneDrive and enables them to classify that data on demand. This helps ensure that Microsoft 365 Copilot is indexing and referencing files in its responses that have been properly classified. Previously, unclassified and unscanned files did not appear in DSPM for AI oversharing assessments. Now admins can initiate an on-demand data classification scan, directly from the oversharing assessment, ensuring that older or previously unscanned files are identified, classified, and incorporated into the reports. This allows organizations to detect and address potential risks more comprehensively. For example, an admin can initiate a scan of legacy customer contracts stored in a specified SharePoint library to detect and classify sensitive information such as account numbers or contact information. If these newly classified documents match the classifiers included in any existing auto-labeling policies, they will be automatically labeled. This helps ensure that documents containing sensitive information remain protected when they are referenced in Microsoft 365 Copilot interactions. Learn More. Security teams can trigger on-demand classification scan results in the oversharing assessment in Purview DSPM for AI. Secure and govern data in Security Copilot and Copilot in Fabric: We are excited to announce the public preview of Purview for Security Copilot and Copilot in Fabric, starting with Copilot in Power BI, offering DSPM for AI, Insider Risk Management, and data compliance controls, including eDiscovery, Audit, Data Lifecycle Management, and Communication Compliance. These capabilities will help organizations enhance data security posture, manage compliance, and mitigate risks more effectively. For example, admins can now use DSPM for AI to discover sensitive data in user prompts and responses and detect unethical or risky AI usage. Purview’s DSPM for AI provides admins with comprehensive reports on user activities and data interactions in Copilot for Power BI, as part of the Copilot in Fabric experience, and Security Copilot. DSPM Discoverability for Communication Compliance: This new feature in Communication Compliance, which will be available in public preview starting May 1, enables organizations to quickly create policies that detect inappropriate messages that could lead to data compliance risks. The new recommendation card on the DSPM for AI page offers a one-click policy creation in Microsoft Purview Communication Compliance, simplifying the detection and mitigation of potential threats, such as regulatory violations or improperly shared sensitive information. With these enhanced capabilities for securing and governing data in Microsoft 365 Copilot and beyond, organizations can confidently embrace AI innovation while maintaining strict security and compliance standards. Explore additional resources As organizations embrace AI, securing and governing its use is more important than ever. Staying informed and equipped with the right tools is key to navigating its challenges. Explore these resources to see how Microsoft Security can help you confidently adopt AI in your organization. Learn more about Security for AI solutions on our webpage Get started with Microsoft Purview Get started with Microsoft Defender for Cloud Sign up for a free Microsoft 365 E5 Security Trial and Microsoft Purview Trial Learn more about the innovations designed to help your organization protect data, defend against cyber threats, and stay compliant. Join Microsoft leaders online at Microsoft Secure on April 9. [1] 2024 Work Trend Index Annual Report, Microsoft and LinkedIn, May 2024, N=31,000. [2] Gartner®, Gartner Peer Community Poll – If your org’s using any virtual assistants with AI capabilities, are you concerned about indirect prompt injection attacks? GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.Exploring the Extensibility of Active Directory Migration Service (ADMS)
Active Directory Migration Service (ADMS), Active Directory Synchronization Service (ADSS), and Active Directory Group Modernization Service (ADGMS) are cloud-based services within the ADxS services portfolio offered by Microsoft. These services are designed to facilitate efficient and cost-effective migrations. In this article, we will examine the various extensibility options of ADMS, highlighting its key features and advantages.Meet the IMS team
In today’s fast-paced digital landscape, identity migration isn’t just a technical process—it’s a critical step in ensuring business continuity, security, and user satisfaction. That’s where our Identity Migration Service (IMS) comes in. A migration platform offering a seamless, IT-friendly, and end-user-focused experience. But what truly sets us apart? Our dedicated team of experts. These are the people who will guide you every step of the way, making your transition smooth, stress-free, and efficient. From initial configuration to the final migration, meet the specialists who ensure your success. So what's in it for you? When you choose IMS, you gain access to a team of highly skilled professionals who are committed to making your migration journey smooth and successful. They will help you set up the best solution for synchronization, user and workstation migration, application remediation, or group modernization whether for an on-prem AD or Entra ID in Azure. Most IT staff come across a migration project once in their career, for the members of the IMS team it’s their daily work. All that knowledge is put into the IMS migration platform so that the focus is on getting the best solution for your company, not on reinventing the wheel. IMS Identity Consultant Our identity consultant specializes in identity management and security. They work closely with your team to understand your current identity infrastructure and develop a customized synchronization and migration plan that addresses your unique needs. This is done through workshops and subsequent meetings. A few examples are: Do you want to modify any attribute when moving an object from source to target? How to handle users with multiple identities? IMS Portal Consultant The portal consultant focuses on the user self-service experience and underlying interfacing aspects of the migration methods. Just like the Identity consultant, they use workshops to determine your needs and translate those into technical implementations. A few examples are: What language support do you want? Is there a need to run external scripts at the time of migration? Are there any prerequisites you want checked before starting the migration? Any applications that require remediation before, during, or after the migration process? IMS Support Team We know that identity migration is a complex process, which is why we offer a support team that is available during local office hours on weekdays. There is an add-on available if you require support outside local office hours (e.g. If you’re operating globally) with a maximum of 24-hour support during weekdays. Once the Identity and Portal consultant finishes the configuration and you sign off on the acceptance tests, this team is ready to assist you with any issues or questions that may arise, ensuring minimal disruption to your operations. IMS Engineering Team Our engineering team is available to customize the IMS platform to match your specific needs. Whether it's integrating with existing systems or optimizing performance, our engineers can work closely with you to ensure that the IMS platform fits your organization's requirements. IMS Project Manager The project manager oversees the entire project on the IMS side, coordinating the efforts of the IMS team and ensuring that the project stays on track. They are your main point of contact and are connected to the project team on the customer side, providing regular updates and addressing any concerns there may be. Why Choose IMS? The skilled IMS team brings a wealth of experience and expertise to your migration project. By working with us, you can expect: Dedicated team: Staffing is included in the offering, the assigned team will be available to you for the duration of the migration project. Seamless Integration: Our team ensures that your identity migration is smooth and hassle-free, minimizing downtime and disruption to your business. Customized Solutions: We tailor our migration service to meet your specific needs, ensuring that your new identity infrastructure is optimized for your organization. Expert Support: With our skilled worldwide support team and the option to extend the support hours, you can rest assured that help is available when you need it. In conclusion, our Identity Migration Service is more than just a technical solution — it's a partnership with a team of dedicated professionals who are committed to your success. Learn more about IMS and its capabilities today on our YouTube channel or have a look at other articles on the IMS blog. Are you in need of more tailored information? Contact imssales@microsoft.com.ADSS TSync vs Entra Cross-Tenant Sync: A Comprehensive Comparison
When managing identities across multiple tenants, organizations often face a crucial decision: should they choose ADSS (Active Directory Synchronization Service) Tenant Sync or Entra Native Cross-Tenant Sync to enable collaboration across tenants? The ADSS Tenant Sync service for Tenant-to-Tenant Synchronization is designed to maintain a single unified global address list between tenants. It synchronizes and provisions users or contacts between tenants and provisions guest accounts for Azure B2B sharing of applications and resources. Cross-Tenant synchronization automates creating, updating, and deleting Microsoft Entra B2B collaboration users across tenants in an organization. It enables users to access applications and collaborate across tenants, while still allowing the organization to evolve. Both solutions aim to streamline identity management, but they differ significantly in terms of architecture, control, security, and overall functionality. Here’s a closer look at each solution, presented with relatable examples to help you make an informed decision based on your organization’s needs. Architecture and Core Functionality Imagine you are in charge of a large organization with multiple subsidiaries, each operating under its own Azure AD tenant. You need a solution to synchronize all these identities, but you're unsure where to start. ADSS Tenant Sync is a managed service provided by Microsoft Consulting - IMS team, utilizing a pull-push model. Here, synchronization rules are configured by Microsoft Consulting, and the ADSS server manages identity synchronization. This model is often preferred for larger, complex organizations, as it centralizes control and often includes expert support. It’s akin to outsourcing a specific task to a trusted third-party expert who sets up and manages the solution for you. Entra Cross-Tenant Sync, in contrast, is a native feature of Entra ID (formerly Azure AD) that follows a push-based model using SCIM (System for Cross-domain Identity Management). Synchronization happens directly from your source tenant, offering greater control and integration within your existing Microsoft ecosystem. It’s like managing your internal processes with a powerful tool that’s built into your existing system—no need for third-party involvement. Control, Authentication, and Security The level of control and the security measures between these solutions differ, particularly when it comes to permissions and access management. ADSS Tenant Sync requires permissions through Microsoft Graph and Exchange Online, demanding specific admin rights, like Exchange Recipient Admin rights and Write permissions for each object type you want to sync. This can feel like managing a series of security checkpoints where each part of the system requires specific access credentials to function properly. Entra Cross-Tenant Sync, on the other hand, simplifies authentication by allowing synchronization policies to be configured directly within both the source and target tenants. This reduces complexity and can be managed more easily, especially in organizations that prioritize ease of access and streamlined workflows. It’s more like having a universal access pass for various departments within a company, eliminating the need for multiple levels of clearance. Data Management, Synchronization, and Filtering When it comes to data handling, there are key differences in how each solution approaches storage and filtering. ADSS Tenant Sync utilizes a centralized identity store within Microsoft-owned Azure subscriptions before synchronizing data to target tenants. This approach allows for complex attribute filtering and customization, such as syncing users as guests or contacts with desired attribute flows and even supports distribution list synchronization as contacts. It’s like having a centralized warehouse where all the data is stored and categorized, allowing for flexibility when choosing what data to sync and how to manage it. In contrast, Entra Cross-Tenant Sync ensures that identities remain within their respective tenants, with no external storage of sensitive identity data. This model is beneficial for organizations concerned about data privacy, as the identities are kept within their home base. Additionally, Entra Cross-Tenant Sync supports syncing users as either external members or guests, depending on configuration. However, it does not support distribution list or contacts synchronization. It’s like keeping all documents in their respective departments to ensure that sensitive information stays within the correct boundaries. Both solutions support object filtering and attribute-based scoping, but ADSS offers more customization in terms of attribute management, making it more flexible for organizations with intricate requirements. Cost, API Support, and Suitable Use Cases Cost and extensibility are crucial factors when considering which solution to adopt. ADSS Tenant Sync operates as a third-party managed service through Microsoft, with a monthly fee attached. It’s ideal for businesses requiring extensive customization, external guest management, and broader synchronization capabilities. The use of Microsoft Graph and PowerShell APIs for extensibility also makes ADSS suitable for organizations that need advanced integrations and a highly tailored solution. Entra Cross-Tenant Sync, on the other hand, is natively integrated into the Microsoft ecosystem. It requires a P1 license for each synchronized user, but the overall cost can be lower compared to ADSS, especially for organizations that do not need extensive customization. The solution uses proprietary APIs managed by the Microsoft Entra Product team, offering a more straightforward, integrated experience. Entra Cross-Tenant Sync is typically more suitable for organizations that prefer an easy-to-manage, cost-effective synchronization solution, without requiring the advanced features of ADSS. Choosing the Right Solution Both ADSS Tenant Sync and Entra Native Cross-Tenant Sync have distinct advantages, and the decision between them depends on your organization’s specific needs. ADSS Tenant Sync is a solid choice for businesses that need advanced features, such as the ability to customize attributes, manage external guests, and support complex synchronization requirements, even if it comes with an additional cost. It’s more suitable for multi-tenant organizations or those working with business partners that require a more tailored solution. Entra Cross-Tenant Sync is a cost-effective, native option that seamlessly integrates into your existing Microsoft environment. It's ideal for enterprises looking for a simpler, more integrated way to manage multi-tenant synchronization without needing complex customization. This solution works well for organizations that prioritize streamlined workflows and less technical overhead. In conclusion, whether you choose ADSS Tenant Sync or Entra Native Cross-Tenant Sync depends on your organization’s goals, the level of customization required, and budget considerations. Both solutions offer effective ways to synchronize identities across tenants, and understanding these differences will help you select the one that aligns best with your infrastructure and long-term identity management goals. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blogs page Watch related videos on our YouTube channel for a seamless, hassle-free migration experience. If you would like to discuss in person, reach out to us at imssales@microsoft.com. Our team will connect with you.
