New Platform SSO with registration during Automated Device Enrollment on macOS
By Iris Yuning Ye, Product Manager – Microsoft Intune & Justin Ploegert, Principal Product Manager – Microsoft Entra A new setting ‘Enable Registration During Setup’ for Platform single sign-on (PSSO) during Automated Device Enrollment (ADE) is now generally available for macOS devices in Microsoft Intune. With this new setting and a compatible version of the Intune Company Portal (5.2604.0 and newer), this feature enables users sign in with their Microsoft Entra account during Setup Assistant, complete device registration before reaching the desktop, and get immediate access to work resources and ready to be productive sooner. Why this matters Previously, Platform SSO registration occurred only after users completed Setup Assistant and reached the desktop. They then had to notice and act on a separate notification to finish Platform SSO registration. When Platform SSO registration isn't completed, it can cause issues with app authentication or lead to noncompliance, delaying users from getting started on the device: Missed notifications - Users dismiss or ignore the post-enrollment PSSO prompt, leaving devices in an incomplete device registration state. Broken app authentication - Apps like Microsoft Outlook could fail to authenticate because SSO isn’t fully configured. Compliance gaps - Devices are flagged as noncompliant in the Intune Company Portal because Platform SSO registration isn’t completed. Helpdesk burden - IT teams field repeated tickets for issues that should have been handled automatically during provisioning. Migration blocker - Incomplete Platform SSO setup slows down migrating macOS devices to Intune. Platform SSO during ADE with EnableRegistrationDuringSetup key eliminates these issues. Device registration, identity bootstrap, and credential setup all happen inline during Setup Assistant before the user ever reaches the desktop. What the feature enables Capability Details Microsoft Entra device registration during ADE The device registers with Microsoft Entra ID before the user reaches the desktop. A hardware-bound Workplace Join certificate is issued and stored securely. Early device identity Device identity is established early in the provisioning process, enabling immediate access to resources protected by Conditional Access. Platform SSO credentials during initial setup When configured with Secure Enclave, credentials are stored in the device's Secure Enclave, providing hardware-bound, phishing-resistant protection aligned with Zero Trust principles. Minimized delays Users arrive at the desktop already signed in. No additional prompts, no waiting for policies, no broken apps. How it works This feature requires three policies that work together. All three must be configured correctly before enrollment starts and assigned to the same static user groups: A Platform SSO settings catalog policy with “Enable Registration During Setup” configured to Enabled. Intune Company Portal (version 5.2604 or newer) deployed as a line-of-business (LOB) app, which provides the Microsoft Enterprise SSO extension. An ADE enrollment profile configured with Setup Assistant with modern authentication and Await final configuration = Yes. When a device enrolls with these three policies in place, here's what happens: The device powers on and begins the ADE enrollment flow. Intune delivers the Platform SSO settings catalog policy with Enable Registration During Setup enabled. Intune Company Portal is installed automatically as a LOB app, providing the Microsoft Enterprise SSO plug-in. During Setup Assistant, the user signs in with their Microsoft Entra credentials. This first sign-in starts the regular enrollment process. A second sign-in authenticates the identity in Intune Company Portal and fetches the SSO extension. The device registers with Microsoft Entra ID, and a Microsoft Entra device registration certificate is issued. The user arrives at the desktop fully authenticated, with SSO active and Conditional Access satisfied. Note: During enrollment, users are prompted to enter their Microsoft Entra credentials at least twice. We're working on improvements to reduce the number of sign-ins in a future update. Prerequisites Requirement Details macOS version macOS 26 and newer Enrollment method ADE via Apple Business Intune Company Portal Version 5.2604.0 or newer, deployed as a LOB app. Download from https://go.microsoft.com/fwlink/?linkid=853070 Intune role for configuration Admin account with at least the Policy and Profile Manager built-in role Group type Assigned (static) user groups only. Dynamic groups and device groups are not supported. Important: Review the full Platform SSO prerequisites in the Platform SSO configuration guide before you begin. High level step-by-step configuration Step 1: Create or update the Platform SSO settings catalog policy In the Microsoft Intune admin center, go to Devices > Manage devices > Configuration. If this is your first time configuring Platform SSO, follow the full Platform SSO configuration guide. Add and configure the following setting: Setting Value Description Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup Enabled Enables the Platform SSO registration process during Setup Assistant. If using the Password authentication method, it’s recommended to add for password sync function: Setting Value Description Authentication > Extensible Single Sign On > Platform SSO > Enable Create First User During Setup Enabled Enables the password synchronization experience during Setup Assistant. Only configure this if using the Password authentication method. Tip: Microsoft recommends using Secure Enclave as the authentication method for the strongest hardware-backed security. Enable Create First User During Setup setting will be available soon in settings catalog. Assign the policy to your static user groups. Filter is also supported with correct static group setting. Step 2: Install Intune Company Portal as a LOB app Download the Company Portal for macOS PKG from https://go.microsoft.com/fwlink/?linkid=853070. In the Intune admin center, go to Apps > All Apps > Create. Add Intune Company Portal as a macOS LOB app. Make it a required app and assign it to the same groups as the Platform SSO policy from Step 1. Important: Company Portal 5.2604.0 and newer is required. If you install an older version, Platform SSO fails. When Intune detects Company Portal as a deployed policy, it sends it with priority during enrollment. And clean up the App bundle ID that are not related to Company Portal, make sure only com.microsoft.CompanyPortalMac as the relevant App bundle ID is kept. Step 3: Set up the enrollment profile In the Intune admin center, go to Devices > Device onboarding > Enrollment > Apple tab. Create or edit an Automated Device Enrollment profile with these Management settings: Setting Value User affinity Enroll with User Affinity Authentication Setup Assistant with modern authentication Await final configuration Yes Locked enrollment Yes Assign the profile to the same devices targeted as Steps 1 and 2. Critical: You must assign all three policies to the same devices targeted. If any policy is assigned to a different group, or if any step is misconfigured, enrollment will fail. In that case, wipe the device and re-enroll with all steps correctly configured. Key things to remember ✅ Three policies, one group: Settings catalog, Company Portal LOB app, and ADE enrollment profile, all assigned to the same static user groups. ✅ Static groups only: This feature does not work with device groups or dynamic groups. ✅ One SSO policy per device: If you already have a Platform SSO policy assigned to enrolled devices, make sure device is wiped appropriately before kicking of enrollment with new PSSO flow. ✅ Latest Intune Company Portal: Version 5.2604.0 or newer is required. ✅ macOS 26 required: This feature is supported on macOS 26 and newer. ✅ Secure Enclave recommended: For the strongest hardware-backed credential protection. For more details, refer to Configure Platform Single Sign-On (PSSO) during Automated Device Enrollment for macOS devices. Looking ahead: Reducing Platform SSO sign-in prompts Signing in multiple times during enrollment isn't the ideal experience, and we're actively working to streamline it with a new enrollment setting that enables users to complete both Intune enrollment and Platform SSO device registration with a single sign-in. This will further simplify the onboarding experience, reduce friction for users, and bring macOS enrollment closer to a truly seamless, zero-touch provisioning flow. Stay tuned to What’s new in Intune for the release. Related resources SSO in ADE profile (new article): Add Platform SSO policy to ADE Profile on macOS devices SSO scenarios: Platform SSO scenarios for macOS devices Platform SSO configuration guide for macOS devices using Microsoft Intune Common Platform SSO scenarios for macOS devices Install Company Portal for macOS as a macOS LOB app Set up automated device enrollment (ADE) Troubleshoot the Microsoft Enterprise SSO Extension plugin on Apple devices macOS Platform single sign-on known issues and troubleshooting As always, we'd love your feedback. If you've piloted Platform SSO during Setup Assistant, share your tips and lessons learned in the comments below or reach out to us on X @IntuneSuppTeam.Microsoft Entra Agent ID explained
See every agent in one place, understand what it can access, detect agent sprawl early, and apply least-privilege permissions using the same Microsoft Entra tools you already use for users — without introducing new governance models. Approve and scope agent access with accountability, enforce agent-specific Conditional Access in real time, automatically block risky behavior, and ensure every agent always has an owner, even as people change roles or leave. Leandro Iwase, Microsoft Entra Senior Product Manager shows how to keep agents operating securely, transparently, and predictably across their entire lifecycle. AI agents get real identities. See how to apply permissions, protections, and policies. Treat agents like human users with Microsoft Entra Agent ID. Gain full visibility for each agent in your tenant. See how many agents exist, which are active or unmanaged, and where sprawl is starting — before it becomes a risk. Check out Microsoft Entra Agent ID. Control what agents can access in real time. Apply Conditional Access policies directly to agents using Microsoft Entra Agent ID. Start here. QUICK LINKS: 00:00 — Treat AI Agents Like Real Identities 00:42 — Stop Agent Sprawl 02:26 — Least Privilege with Agent Blueprints 03:39 — Scope Agent Access 05:10 — Create agent specific Conditional Access policies 06:12 — Protect against a sponsor account 07:01 — Agents flagged as risky 07:50 — Ownerless agents 09:00 — Wrap up Link References Check out https://aka.ms/EntraAgentID Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -As more AI agents become active in your environment, you need control over them and what they can access. That’s where Microsoft Entra Agent ID comes in. It lets you treat agents like you would treat human users with their own built-in identities. Agent ID lets you define permissions and extend new and existing protections to them. You stay in control across their entire life cycle, from initial creation to monitoring the day-to-day activities where we continuously check for risk and protect access to resources, to switching their ownership if their sponsors no longer around, and disabling them when they’re no longer needed. The good news is that you can use the same tools in Microsoft Entra that they use to manage human identities today. Let me show you. Here in the Entra Domain Center, you see a new type under Entra ID called Agent ID. In the overview, you’ll find a summary with key metrics. These insights highlight what you need to know about your agents. -For example, how many agents are in your tenant, the number of agents recently created, how many are active or unmanaged and without identities. Each are starting point for understanding agent activity and spotting early signs of agent sprawl. Moving to the agent registry, you get visibility for each agent in your tenant and what platform they were built on and whether they have an Agent ID or not. The agents here are mixture of Microsoft-built agents, agents that you built in Microsoft Foundry, Copilot Studio, as well as Security Copilot. And no Microsoft agents using APIs and SDK supporting Agent ID. In fact, Agent Registry in Microsoft Entra is a shared center registry also used by the Agent 365 control plane. Next, in our agent identities, we can see all AI agents with an agent ID. Here, each agent automatically gets identity record, which is immutable object ID, just like a user or app registration would. It can quickly filter the list of the agents I want to manage. And by clicking into an agent like this one for HR self-service, we can see each details like the agent status, sponsor, permissions, roles, and associated policies. -Then, agent blueprints are templates for how agent identities are created. They ensure that any agent created has the right controls and is aligned with organizational policies. In the blueprint, we can see that it has one linked agent identity, which is actually itself. That said, this blueprint could be used for other agents as they are created. In fact, let me show you how this works with a blueprint that has more linked agent IDs. Back in our agent identities view, I’ll take a look at this HR Test agent to verify its agent blueprint. Here’s one has two linked agent identities. One has been named an Actor agent and is active. I’ll click into its access details. Here, I can see the details for each permissions. It has Application.ReadWrite.All permissions in the Microsoft Graph, which means it’s over permission, so it’s potentially dangerous. If I go back to the agent page, I can disable this agent. And if I confirm, this will block the agent to improve security and prevent and authorize access to it. So as an administrator, you have full visibility into your agent details and their correspondent permissions for accessing your resources. -Next, for scoping access to just what an agent needs to perform his tasks, we use access packages in Microsoft Entra. Let me show you. We start under Identity Governance, from Entitlement management and Access packages. You can see that I’ve already got one for a sponsor-initiated access package created. This includes the resources to help automate HR-related tasks for our agents. In Resource roles, you can see the specific Microsoft Graph API-related roles. Under Policies, that is just one initial policy. And clicking into it, we can see who can request access. I can choose from Admin, Self, Agent Sponsor, or Owner. -Importantly, these access package requires agent sponsor to approve any agent requests for access and it requires a business justification as well. Let me show you how the access request process works. I’m logged in as a human agent sponsor with the My Access portal open. I’ll browse Available access package. And here, the Sponsor-Initiated Agent Access package that we saw before. Clicking to exposes which identity I’m requesting access for, and I’ll keep the Sponsor agent option, and I’ll choose our HR Actions Agent. Next, I just need to enter a business justification. I’ll enter Timebound access for HR agents, then submit the request. Once the request has been approved, the agent will work according to my policies. And now, I can even create specific conditional access policies that will assess this realtime as agents try to access resources. -Here, I’ve created a Conditional Access policy to prevent agents from requesting sensitive information. In Assignments, there is now an option to apply the policy to agents. Under Grant, you see that this policy blocks all access requests by default, and you can see all agent identities are in scope. In my case, I want to make one exception. I want to make sure only approve HR agents can access HR information and stop our other agents. We can do that using an exclusion for HR-approved agents. Back in my policy, if I move over to Exclude, I can exclude one or more agent IDs from the policy. Using filter rules, this is how I can only allow the agents that were approved by HR to get access to dedicated HR resources, as you can see here. Under Target resources and in the filter, you also see that this policy covers all resources. So that was a very target Conditional Access policy. -We can also apply broader policies for all agents at risk to protect against a sponsor accounting being compromised and giving the agent malicious instructions. I move over to another Conditional Access policy that I’ve started. Just notice the identities in scope are, again, all agents. Target resources are all resources. But under Conditions, there is a new one called Agent risk. And when I’m look at what’s configured, you see the now we have High, Medium, and Low risk level options. I’ve chosen High. And once that’s enabled, condition access, you assess agent risk in realtime based on its likelihood of compromise and automatically block access to any resource per this policy scope. -Now, we’ve protected from risk agents when they request access to resources. And from Microsoft Entra, you can see which agents are currently flagged as risky in your tenant. Right from Identity Protection, you find your risky agents. So let’s take a look. We have three of them here. Our HR Actor agent from before shows high risk. By clicking in, you can see why. It looks like this agent tried to access resources that it does not usually access. Remember, this policy was a scoped to all agents without any exclusions, so if you block our HR agents too in case high risk is detected. So now our agents are running with their own identities and our resources are protected. -Since agents have one or more human sponsor, let’s move on to what happens if a sponsor leaves or change roles and makes the agent ownerless. For that, using lifecycle workflows, we can automatically notify the right people when agents become ownerless. Work workflows are a great way to automate routine tasks like employee onboarding and offboarding, and they work for agents too. I will narrow my list down by searching for a sponsor. There’s my workflow for AI agents to configure their sponsor in the event of a job profile change. Drilling into the workflow and then into its tasks, you see that we have two tasks defined for the what happens when the job profile changes. The first is an email to notify the manager of the user move, and I’ll click into the second task, which sends an email to the manager to notify them about agent identity sponsorship change they will need to action. -Let me show you an example when an agent sponsor leaves their role. Here, we’re seeing the manager’s mobile device. There’s a come in for an Outlook. And when we open it, in the mail, we can see that the manager needs to identify a sponsor for the two HR agents listed. This way, you can ensure the agents always have assigned sponsors. -Microsoft Entra Agent ID provides comprehensive identity, access, and lifecycle management for agents, with the same familiar tools you leverage already for users. To learn more, checkout aka.ms/EntraAgentID. Keep checking back to Microsoft Mechanics for the latest tech updates, and thanks for watching.
Unable to login to purview once Classic interface retired
Once Microsoft forced the retirement of the Classic portal, I have been unable to login to Purview. I opened a case and it went nowhere, we have not changed anything with our account permissions or roles during this period, but Microsoft obviously changed something drastic. We'd been using Purview classic without any problems, we simply got a message last year that "Microsoft had migrated us" and never worked since. Earlier in the year, we'd encounter an error, now (without changing anything) we get to a screen that reads "Select a Microsoft Purview account" and it lists our Microsoft Entra ID (only one to choose) but the next prompt to select from a drop-down under "Account name" has no options. Is Microsoft documenting common scenarios for what they've broken? Support refused (or were unable) to actually dig into our tenant or configuration to look, they just sent article after article that didn't apply to our situation.How to move Active Directory Source of Authority to Microsoft Entra ID and why
This gives you seamless access for your teams, stronger authentication with MFA and passwordless options, and centralized visibility into risks across your environment. Simplify hybrid identity management by reducing dual overhead, prioritizing key groups, migrating users without disruption, and automating policies with Graph or PowerShell. Jeremy Chapman, Microsoft 365 Director, shows how to start minimizing your local directory and make Microsoft Entra your source of authority to protect access everywhere. Strengthen your identity security. Sync your on-prem AD with Microsoft Entra ID, adding MFA and Single Sign-on. Start here. Gain full visibility into risky sign-ins. Minimize dual management by moving the source of authority to Microsoft Entra. Check it out. Automate moving groups and users to the cloud. Streamline your identity management using Graph API or PowerShell. Take a look. QUICK LINKS: 00:00 — Minimize Active Directory with Microsoft Entra 00:34 — Build a Strong Identity Foundation 01:28 — Reduce Dual Management Overhead 02:06 — Begin with Groups 03:04 — Automate with Graph & Policy Controls 03:50 — Access packages 06:00 — Move user objects to be cloud-managed 07:03 — Automate using scripts or code 09:17 — Wrap up Link References Get started at https://aka.ms/CloudManagedIdentity Use SOA scenarios at https://aka.ms/usersoadocs Group SOA scenarios at https://aka.ms/groupsoadocs Guidance for IT Architects on benefits of SOA at https://aka.ms/SOAITArchitectsGuidance Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -Your identity system is your first and last line of defense against unauthorized access, data exfiltration, and lateral movement. And now with AI agents acting on behalf of users, identity is more critical than ever. Today we’re going to explain and demonstrate how moving more of your groups and users to centralized management in the cloud can increase your identity security posture without breaking access and authorization to the resources that you have running on premises so that your users don’t even notice anything changed. If we step back in an architectural level, if yours is like most organizations, you’re probably running hybrid identity, where core identity management tasks happen on your local infrastructure, and many of your user, group, app and device accounts are still created or exist on-prem. -And as you’ve started using cloud services, you’ve also set up identity synchronization between your local Active Directory and Microsoft Entra ID so that you can synchronize on-prem objects like usernames, passwords, and groups to the cloud. And if you’ve then gotten the extra step of a Cloud first approach, your new users, apps, and groups are managed in Microsoft Entra by default, and your new managed devices are Entra Joined. Now, you should have implemented multifactor authentication, ideally phish-resistant MFA with device compliance checks along with Single Sign-on for your apps. In both cases, these are really strong foundations. -That said, though, you’re dealing with dual management overhead, on-premises and in the cloud, which can result in less visibility and policy gaps. Moving the Source of Authority to Microsoft Entra to manage identity from the cloud across your digital estate, solves this. Here you’re minimizing your local directory services to only what’s necessary and bringing your existing groups, users and devices as well as your apps and cloud services wherever they live, into Microsoft Entra, which gives you holistic visibility and access control into user sign-ins, risky behaviors, and more across your environment. -In fact, as I’ll show you, this approach even improves controls as users access on-premises resources. The best path to making Microsoft Entra the source of authority is to start with your Active Directory Security Groups where you’ll prioritize the apps that you want to move to cloud-based authentication. Then after working through those, you’ll turn your attention to moving existing user accounts to the cloud. Let me show you how, starting with groups. So here you’re seeing a synced group in Microsoft Entra. The ExpenseAppUsers group has its source in Windows Server Active Directory, as you can see here. In fact, if I move over to the server itself and into Active Directory, you’ll see this group here on top. -Now I’m going to go open that up and you’ll take a look at the group membership tab here, and you’ll see that the group currently has two members, Dan and Sandy. And this is the expense app that we actually want to move. It’s a local on-premises line of business app. So let’s go back to Microsoft Entra and move this group. So we’re going to use Graph API to do this, and for that we’ll need the Object ID. So I’ve already copied the Object ID and I’ve pasted that value into this URI and the Graph Explorer. And of course this can be done using PowerShell or in code, too. And I’ve already run a GET command on this Object ID. And you can see that this new parameter IsCloudManaged equals False below. Now, to change this group to be cloud managed, I just need to patch this object with IsCloudManaged:true. Then I’ll run it. -Now if I select the GET command for that same object. Below, we’re going to see that it’s changed from False to True for IsCloudManaged. And if I go back to Microsoft Entra, we can confirm that it’s cloud managed as the group Source. So now we can add users to the group from Microsoft Entra using Access Packages. So from Access Packages, I’m going to open up the one for our app. Then under Policies, I can see the Initial Policy and edit it. Now moving to the Request tab, I’ll add our newly cloud managed group. There it is, ExpenseAppUsers, and confirm. Now I’ll just click through the tabs and finally update the policy. Of course, self-service access requests and reviews will work as well. And now we can actually try this out by adding users from the Microsoft Entra admin center to grant them access to our on-premises Expense App. -So back in our group for the Expense App, I’ll go ahead and navigate to members and there are the two that we saw before from Active Directory. Now let’s add another member. So I’m going to search here for Mike, there he is, and pick his account, then select to confirm. Now if I take a look at Mike’s account properties and scroll down, we’ll see that he’s an On-premises synced account account. So this account is managed in our local Active Directory, but now the group source of authority is actually in Microsoft Entra and I can grant the account access to on-premises resources as well from the cloud. In fact, let’s take a look at how this appears in our local AD. -So now if I open up our ExpenseAppUsers group and I go to the Members tab, you can see that Mike is there as a new member, synced down from the cloud. Under the covers, this is using a matching Group SID and assigning new members to our local group based on our configurations in Microsoft Entra. So, no changes are even necessary in the local directory or the app. And the point of doing this was to ensure that Mike could be granted access to our on-premises Expense App. So let’s see if that worked. So from Mike’s PC, this is his view of the Expense App and he now has access to that local resource even though I made all the configurations in the cloud. So that was how to get groups managed in the cloud and you’d work through other groups based on the priority of the apps and corresponding groups that you want to move to the cloud. -Now the next step is then to move your user objects to be cloud managed by Microsoft Entra. So here I’m in Microsoft Entra, and I’m looking at our Sandy Pass user account, and we saw her account before in Active Directory. And if I scroll down, you’ll see that her account is indeed managed on premises and synced up to Microsoft Entra. Now the goal here is to ensure that we maintain seamless access to on-premises resources like our app that we saw before, or also file shares, for example, with better security using passwordless authentication. So if I move over to the view from Sandy’s PC, you’ll see that she has a hybrid joined account, and I can access local file shares like this one, for example, for DanAppServer. -Now if I head over to the System Tray, you’ll see that this machine also has Global Secure Access running for on-premises resource access. And next, I’ll open up a command prompt and I’ll run klist to see the issued Kerberos Tickets to show domain authorization is indeed working. So now let’s move this account to be cloud managed like we did with our group before. And the process is pretty similar and equally automatable using scripts or code. Again, we’ll need the Object ID from Microsoft Entra. Remember this text string. Now if I move over to Graph Explorer again in the URI, you’ll see that the Object ID for Sandy’s account is already there and I’ve already run the GET command and IsCloudManaged as you would expect is currently False. So let’s change that property to True. And again, I’ll use the PATCH command like we do with the Group, and I’ll run it. So now if I go over to the dropdown and rerun the GET command, you’ll see that IsCloudManaged is now True. -So if I go back to the Entra portal, we can then head over to the account properties and scroll down and then we’ll see that On-premises sync enabled says No. So, Sandy is now managed in the cloud. In fact, let’s head back over to Sandy’s machine and I’m going to purge the klist just to ensure that there aren’t any residual tickets to grant access to on-premises resources. Now I’m going to run dsregcmd and a switch for refreshprt to refresh the primary refresh token. Then running the status switch, I can get all of the details for the device registration. Then if I scroll down, eventually I can see the OnPremTgt and CloudTgt are both YES, which means the Kerberos ticket, granting ticket is working. -So now if I sign out of this machine then sign back in, the meerkat on screen looks pretty optimistic. So I’ll go ahead and open the Start menu, then I’ll head over to our file share from before and no problems. And I still have write permissions, too. So I’ll go ahead and create a folder, now I’ll name it Employee Data, then drag a file into it just to make sure that my experience wasn’t compromised and everything works. So now if I open up Start and then the Command Prompt and then run klist, there are my two issued tickets for the login as well as the file share access respectively. Again, the account is cloud managed now and we moved from on-premises and we haven’t even affected access or authorization to our resources on the local network. We’re still getting Kerberos Tickets, and our user didn’t even notice the change. -Moving your on-premises groups and user objects to be cloud managed is one of the strongest ways to improve your security posture, add control and better visibility. Now to find out more and get started, check out aka.ms/CloudManagedIdentity and keep checking back to Microsoft Mechanics for the latest tech updates, and thanks so much for watching.¿Qué es Microsoft Entra y por qué deberías elegirla para proteger tus aplicaciones?
[Blog post original - en inglés] Microsoft Entra es una familia de productos de identidad y acceso a la red, diseñados para implementar una estrategia de seguridad de Zero Trust (Confianza Cero). Forma parte del portafolio de Microsoft Security, que también incluye: Microsoft Defender para la protección contra amenazas cibernéticas y la seguridad en la nube, Microsoft Sentinel para la información de seguridad y la administración de eventos (SIEM), Microsoft Purview para el cumplimiento, Microsoft Priva para privacidad y Microsoft Intune para la administración de endpoints. Estrategia de seguridad Zero Trust La estrategia de seguridad Zero Trust es un enfoque moderno de ciberseguridad que asume que no se debe confiar en ningún usuario o dispositivo, ya sea dentro o fuera de la red, de forma predeterminada. En su lugar, cada solicitud de acceso debe verificarse y autenticarse antes de conceder acceso a los recursos. Esta estrategia está diseñada para abordar las complejidades del entorno digital moderno, incluyendo el trabajo remoto, los servicios en la nube y los dispositivos móviles. ¿Por qué utilizar Entra? Microsoft Entra ID (anteriormente conocido como Azure AD) es una solución de administración de identidades y acceso en la nube que ofrece varias ventajas sobre las soluciones locales tradicionales: Gestión unificada de identidades: Entra ofrece una solución integral para la gestión de identidades y accesos, abarcando tanto entornos híbridos como en la nube. Esto permite administrar de manera unificada las identidades de los usuarios, sus derechos de acceso y permisos, simplificando la administración y mejorando la seguridad. Experiencias de usuario fluidas: Entra admite el inicio de sesión único (SSO), permitiendo a los usuarios acceder a múltiples aplicaciones con un solo conjunto de credenciales. Esto reduce la fatiga de contraseñas y mejora la experiencia del usuario. Políticas de acceso adaptables: Entra permite una autenticación robusta y políticas de acceso adaptativo en tiempo real basadas en riesgos, sin comprometer la experiencia del usuario. Esto ayuda a proteger de manera efectiva el acceso a los recursos y datos. Integración con identidades externas: Entra External ID permite a las organizaciones administrar y autenticar de forma segura a los usuarios que no forman parte de su fuerza laboral interna, como clientes, socios y otros colaboradores externos. Esto es particularmente útil para las empresas que necesitan colaborar de manera segura con socios externos. Desafío del mercado abordado: Entra enfrenta el desafío del mercado al proporcionar una solución integral de IAM en entornos híbridos y en la nube, garantizando la seguridad, simplificando la autenticación de usuarios y permitiendo el acceso seguro a los recursos. Escalabilidad: Las soluciones en la nube como Entra pueden escalar fácilmente para adaptarse a un número creciente de usuarios y aplicaciones sin necesidad de hardware o infraestructura adicional. Rentabilidad: Mediante el uso de una solución en la nube, las organizaciones pueden reducir los costes asociados al mantenimiento de la infraestructura local, como los servidores y los equipos de red. Flexibilidad: Entra ofrece flexibilidad en términos de implementación e integración con diversas aplicaciones y servicios, tanto dentro como fuera del ecosistema de Microsoft. Seguridad: Las soluciones en la nube suelen incluir funciones de seguridad integradas y actualizaciones periódicas para protegerse contra amenazas emergentes. Entra ofrece un soporte solido para el acceso condicional y la autenticación multifactor (MFA), esenciales para proteger los datos confidenciales. Como puedes ver, hay muchas razones para explorar Entra y su conjunto de productos. Más sobre los productos Entra Microsoft Entra está diseñado para proporcionar administración de identidades y accesos, gestión de infraestructura en la nube y verificación de identidad. Funciona en: Las instalaciones. A través de Azure, AWS, Google Cloud. Aplicaciones, sitios web y dispositivos de Microsoft y de terceros. Estos son los productos y soluciones clave dentro de la familia de productos Microsoft Entra. Microsoft Entra ID: Se trata de una solución integral de gestión de identidades y accesos que incluye características como el acceso condicional, el control de acceso basado en roles, la autenticación multifactor y la protección de la identidad. Entra ID ayuda a las organizaciones a administrar y proteger identidades, garantizando un acceso seguro a aplicaciones, dispositivos y datos. Microsoft Entra Domain Services: Este producto proporciona servicios de dominio administrados, como la unión a dominio, políticas de grupo, el Protocolo Ligero de Acceso a Directorios (LDAP) y la autenticación Kerberos/NTLM. Permite a las organizaciones ejecutar aplicaciones heredadas en la nube que no pueden usar métodos de autenticación modernos o en las que no se desea que las búsquedas de directorio vuelvan siempre a un entorno local de Servicios de Dominio de Active Directory (AD DS). Puedes migrar esas aplicaciones heredadas de tu entorno local a un dominio administrado, sin necesidad de administrar el entorno de AD DS en la nube. Microsoft Entra Private Access: proporciona a los usuarios, ya sea en la oficina o trabajando de forma remota, acceso seguro a recursos privados y corporativos. Permite a los usuarios remotos conectarse a los recursos internos desde cualquier dispositivo y red, sin necesidad de una red privada virtual (VPN). El servicio ofrece acceso adaptable por aplicación basado en directivas de acceso condicional, proporcionando una seguridad más granular que una VPN. Microsoft Entra Internet Access: asegura el acceso a los servicios de Microsoft, SaaS y aplicaciones públicas de Internet, mientras protege a los usuarios, dispositivos y datos frente a las amenazas de Internet. Esto se logra a través de la puerta de enlace web segura (SWG) de Microsoft Entra Internet Access, que está centrada en la identidad, es consciente de los dispositivos y se entrega en la nube. Microsoft Entra ID Governance es una solución de gobernanza de identidades que ayuda a garantizar que las personas adecuadas tengan el acceso adecuado a los recursos correctos en el momento oportuno. Esto se logra mediante la automatización de las solicitudes de acceso, las asignaciones y las revisiones a través de la administración del ciclo de vida de la identidad. Microsoft Entra ID Protection ayuda a las organizaciones a detectar, investigar y corregir los riesgos basados en la identidad. Estos riesgos pueden integrarse en herramientas como el acceso condicional para tomar decisiones de acceso, o retroalimentar una herramienta de administración de eventos e información de seguridad (SIEM) para una mayor investigación y correlación. 7. Microsoft Entra Verified ID es un servicio de verificación de credenciales basado en estándares abiertos de identidades descentralizadas (DID). Este producto está diseñado para la verificación y gestión de identidades, garantizando que las identidades de los usuarios se verifiquen de forma segura. Admite escenarios como la verificación de credenciales laborales en LinkedIn. 8. Microsoft Entra External ID se centra en la administración de identidades externas, como clientes, socios y otros colaboradores que no forman parte de la fuerza laboral interna. Permite a las organizaciones administrar y autenticar de forma segura a estos usuarios externos, proporcionando características como experiencias de registro personalizadas, flujos de registro de autoservicio y administración de usuarios. 9. Administración de permisos de Microsoft Entra: Este producto se ocupa de la administración de permisos y controles de acceso en varios sistemas y aplicaciones, garantizando que los usuarios tengan el nivel adecuado de acceso. Permite a las organizaciones detectar, ajustar automáticamente y supervisar continuamente los permisos excesivos y no utilizados en Microsoft Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP). 10. Microsoft Entra Workload ID: Este producto ayuda a las aplicaciones, contenedores y servicios a acceder de forma segura a los recursos en la nube, proporcionando administración de identidad y acceso para la carga de trabajo. ¿Qué producto Entra elegir? Hemos explicado algunos productos importantes, pero es posible que aún te preguntes cuál elegir. Veamos algunos escenarios para ayudarte a decidir Escenario: Integración de GitHub Actions Un equipo de desarrollo usa GitHub Actions para la integración continua y las canalizaciones de implementación continua (CI/CD). Necesitan acceder de forma segura a los recursos de Azure sin administrar secretos. Producto recomendado: Entra Workload ID ¿Por qué Entra Workload ID? El identificador de carga de trabajo de Microsoft Entra admite la federación de identidades de carga de trabajo, lo que permite a GitHub Actions acceder a los recursos de Azure de forma segura mediante la federación de identidades de GitHub. Esto elimina la necesidad de administrar secretos y reduce el riesgo de fugas de credenciales. Escenario: Gestión interna del acceso de los empleados Una gran empresa necesita gestionar el acceso a sus aplicaciones y recursos internos para miles de empleados. La organización desea implementar la autenticación multifactor (MFA), las directivas de acceso condicional y el control de acceso basado en roles (RBAC) para garantizar un acceso seguro. Producto recomendado: Entra ID ¿Por qué Entra ID? Microsoft Entra ID es ideal para este escenario, ya que proporciona soluciones completas de administración de identidades y acceso, como MFA, acceso condicional y RBAC. Estas características ayudan a garantizar que solo los empleados autorizados puedan acceder a recursos confidenciales, mejorando la seguridad y el cumplimiento. Escenario: Inicio de sesión único (SSO) para aplicaciones internas Una empresa quiere agilizar el proceso de inicio de sesión de sus empleados mediante la implementación de Single Sign-On (SSO) en todas las aplicaciones internas, incluidas Microsoft 365, Salesforce y aplicaciones personalizadas. Producto recomendado: Entra ID ¿Por qué Entra ID? Microsoft Entra ID admite SSO, lo que permite a los empleados usar un único conjunto de credenciales para acceder a varias aplicaciones. Esto mejora la experiencia del usuario, reduce la fatiga de las contraseñas y mejora la seguridad al centralizar la autenticación y la gestión del acceso. Escenario: Cargas de trabajo de Kubernetes Una organización ejecuta varias aplicaciones en clústeres de Kubernetes y necesita acceder de forma segura a los recursos de Azure desde estas cargas de trabajo. Producto recomendado: Entra Workload ID ¿Por qué Entra Workload ID? Entra Workload ID permite que las cargas de trabajo de Kubernetes accedan a los recursos de Azure sin administrar credenciales ni secretos. Al establecer una relación de confianza entre las cuentas de servicio de Azure y Kubernetes, las cargas de trabajo pueden intercambiar tokens de confianza por tokens de acceso de Microsoft Identity Platform. Escenario: Empresa de comercio electrónico, portal del cliente Una empresa de comercio electrónico quiere crear un portal de clientes en el que los usuarios puedan registrarse, iniciar sesión y gestionar sus cuentas. La empresa debe proporcionar una experiencia de registro e inicio de sesión segura y fluida para sus clientes. Producto recomendado: Entra External ID ¿Por qué Entra External ID? El identificador externo de Microsoft Entra está diseñado para administrar identidades externas, como los clientes. Ofrece características como experiencias de registro personalizadas, flujos de registro de autoservicio y autenticación segura, lo que lo convierte en la opción perfecta para crear un portal de clientes. Escenario: Colaboración de socios Una empresa de fabricación colabora con múltiples socios y proveedores externos. La empresa debe proporcionar acceso seguro a los recursos y aplicaciones compartidos y, al mismo tiempo, garantizar que solo los socios autorizados puedan acceder a datos específicos. Producto recomendado: Entra External ID ¿Por qué Entra External ID? El identificador externo de Microsoft Entra es ideal para administrar identidades externas, como asociados y proveedores. Permite a la empresa gestionar y autenticar de forma segura a los usuarios externos, proporcionando funciones como la colaboración B2B y la gestión de acceso, garantizando que solo los socios autorizados puedan acceder a los recursos necesarios. Primeros pasos con Entra ID Por último, te recomendamos algunos recursos estupendos. Microsoft Identity Platform Dev Center Plataforma con documentos, tutoriales, vídeos y más Microsoft identity platform Dev Center | Identity and access for a connected world | Microsoft Developer Aprendizaje sobre Microsoft Entra ID Aumenta tus habilidades en Microsoft Learn Introducción a Microsoft Entra ¿Qué es Microsoft Entra ID? Página de inicio con documentos oficiales que explican Entra ID: un gran lugar para comenzar ¿Qué es Microsoft Entra ID? Tutorial: Inicia sesión de usuario en Entra Node.js tutorial Tutorial: Inicio de sesión de usuarios y adquisición de un token para Microsoft Graph en una aplicación web de Node.js y Express Tutorial: Agregar inicio de sesión con Microsoft Entra Java tutorial Add sign-in with Microsoft Entra account to a Spring web app - Java on Azure | Microsoft Learn Tutorial: Registra una aplicación de Python con Entra Python tutorial Tutorial: Register a Python web app with the Microsoft identity platform - Microsoft identity platform | Microsoft Learn Tutorial: Registra una aplicación de .NET con Entra .NET Core Tutorial: Register an application with the Microsoft identity platform - Microsoft identity platform | Microsoft Learn Primeros pasos con Entra External ID One stop shop, Plataforma de identidad para programadores. Gran punto de comienzo para aprender sobre noticias, documentos, tutoriales, vídeos y más Microsoft Entra External ID | Simplify customer identity management | Microsoft Developer Tutorial: Añade autenticación a una aplicación Vanilla SPA JavaScript tutorial Tutorial: Create a Vanilla JavaScript SPA for authentication in an external tenant - Microsoft Entra External ID | Microsoft Learn Tutorial: Iniciar sesión de usuarios en Node.js aplicación JavaScript/Node.js tutorial Sign in users in a sample Node.js web application - Microsoft Entra External ID | Microsoft Learn Tutorial: Inicio de sesión de usuarios en ASP.NET Core .NET Core tutorial Sign in users to a sample ASP.NET Core web application - Microsoft Entra External ID | Microsoft Learn Iniciar sesión con usuarios en una aplicación Python Flask Python tutorial Sign in users in a sample Python Flask web application - Microsoft Entra External ID | Microsoft Learn Tutorial: Inicio de sesión de usuarios en una aplicación Node.js JavaScript/Node.js tutorial Tutorial: Prepare your external tenant to sign in users in a Node.js web app - Microsoft Entra External ID | Microsoft Learn Tutorial: Inicio de sesión de usuarios en una aplicación .NET Core .NET Core Tutorial Tutorial: Prepare your external tenant to authenticate users in an ASP.NET Core web app - Microsoft Entra External ID | Microsoft Learn Resumen y conclusiones En resumen, te presentamos Entra y algunos de sus productos dentro de una gran familia de soluciones. También te mostramos algunos escenarios y qué productos encajarían mejor en cada uno. Esperamos que hayas tenido un gran comienzo, ¡gracias por leer!
Entra Groups and managing Access to Teams or Town Hall
Wouldn't it be great if there was a way to grant access to a Teams or Town Hall meeting using an Entra ID Group without inviting all the users in the Group? This way you could send the meeting link to users in the Group as needed. For large organizations with many external partners managed in Entra, this would be very beneficial. This can be done already with the meeting recordings in Stream via the Share button.
