Acrolinx on Passwordless articles

This commit is contained in:
Paolo Matarazzo 2024-01-29 08:22:57 -05:00
parent 9cc97b0061
commit 1947caccb2
4 changed files with 43 additions and 43 deletions

View File

@ -2,7 +2,7 @@
title: Passwordless strategy overview title: Passwordless strategy overview
description: Learn about the passwordless strategy and how Windows security features help implementing it. description: Learn about the passwordless strategy and how Windows security features help implementing it.
ms.topic: concept-article ms.topic: concept-article
ms.date: 12/13/2023 ms.date: 01/29/2024
--- ---
# Passwordless strategy overview # Passwordless strategy overview
@ -23,7 +23,7 @@ Microsoft is working hard to create a world where passwords are no longer needed
:::row-end::: :::row-end:::
Before you move away from passwords, you need something to replace them. Windows Hello for Business and FIDO2 security keys offer a strong, hardware-protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.\ Before you move away from passwords, you need something to replace them. Windows Hello for Business and FIDO2 security keys offer a strong, hardware-protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.\
Deploy Windows Hello for Business or FIDO2 security keys is the first step toward a passwordless environment. Users are likely to use these features because of their convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative solution to passwords, and getting users accostumed to it. Deploy Windows Hello for Business or FIDO2 security keys is the first step toward a passwordless environment. Users are likely to use these features because of their convenience, especially when combined with biometrics. However, some workflows and applications might still need passwords. This early stage is about implementing an alternative solution to passwords, and getting users accustomed to it.
:::row::: :::row:::
:::column span="1"::: :::column span="1":::
@ -69,17 +69,17 @@ The most intuitive answer is the size of the organization, but what exactly defi
| Size factor | Details | | Size factor | Details |
|--|--| |--|--|
| **Number of departments**|The number of departments within an organization varies. Most organizations have a common set of departments such as *executive leadership*, *human resources*, *accounting*, *sales*, and *marketing*. Small organizations may not explicitly segment their departments, while larger ones may. Additionally, there may be subdepartments, and subdepartments of those subdepartments as well.<br><br>You need to know all the departments within your organization, and you need to know which departments use computers and which ones don't. It's fine if a department doesn't use computers (probably rare, but acceptable). This circumstance means there's one less department with which you need to concern yourself. Nevertheless, ensure this department is in your list and you've assessed that it's not applicable.<br><br>Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those departments that will put you and your staff on the road to password freedom. Realistically, many of us lose sight of our organizational chart and how it grows or shrinks over time. This realization is why you need to inventory all of them. Also, don't forget to include external departments such as vendors or federated partners. If your organization goes passwordless, but your partners continue to use passwords and then access your corporate resources, you should know about it and include them in your passwordless strategy.| | **Number of departments**|The number of departments within an organization varies. Most organizations have a common set of departments such as *executive leadership*, *human resources*, *accounting*, *sales*, and *marketing*. Small organizations might not explicitly segment their departments, while larger ones might. Additionally, there may be subdepartments, and subdepartments of those subdepartments as well.<br><br>You need to know all the departments within your organization, and you need to know which departments use computers and which ones don't. It's fine if a department doesn't use computers (probably rare, but acceptable). This circumstance means there's one less department with which you need to concern yourself. Nevertheless, ensure this department is in your list and that it's not applicable.<br><br>Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those departments that put you and your staff on the road to password freedom. Realistically, many of us lose sight of our organizational chart and how it grows or shrinks over time. This realization is why you need to inventory all of them. Also, don't forget to include external departments such as vendors or federated partners. If your organization goes passwordless, but your partners continue to use passwords to access your corporate resources, you should know about it and include them in your passwordless strategy.|
| **Organization or department hierarchy**|Organization and department hierarchy is the management layers within the departments or the organization as a whole. How the device is used, what applications and how they're used, most likely differs between each department, but also within the structure of the department. To determine the correct passwordless strategy, you need to know these differences across your organization. An executive leader is likely to use their device differently compared to a member of middle management in the sales department. Both of those user cases are probably different to how an individual contributor in the customer service department uses their device.| | **Organization or department hierarchy**|Organization and department hierarchy is the management layers within the departments or the organization as a whole. How the device is used, what applications and how they're used, most likely differs between each department, but also within the structure of the department. To determine the correct passwordless strategy, you need to know these differences across your organization. An executive leader is likely to use their device differently compared to a member of middle management in the sales department. Both of those user cases are probably different to how an individual contributor in the customer service department uses their device.|
| **Number and type of applications and services**|Most organizations have many applications and rarely have one centralized list that's accurate. Applications and services are the most critical items in your passwordless assessment. Applications and services take considerable effort to move to a different type of authentication. Changing policies and procedures can be a daunting task. Consider the trade-off between updating your standard operating procedures and security policies compared to changing 100 lines (or more) of authentication code in the critical path of your internally developed CRM application.<br><br>Capturing the number of applications used is easier once you have the departments, their hierarchy, and their stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You can now associate the applications that are used by all levels within each department. You'll also want to document whether the application is internally developed or commercially available off-the-shelf. If the latter, document the manufacturer and the version. Also, don't forget web-based applications or services when inventorying applications.| | **Number and type of applications and services**|Most organizations have many applications and rarely have one centralized list that's accurate. Applications and services are the most critical items in your passwordless assessment. Applications and services take considerable effort to move to a different type of authentication. Changing policies and procedures can be a daunting task. Consider the trade-off between updating your standard operating procedures and security policies compared to changing 100 lines (or more) of authentication code in the critical path of your internally developed CRM application.<br><br>Capturing the number of applications used is easier once you have the departments, their hierarchy, and their stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You can now associate the applications that are used by all levels within each department. You also want to document whether the application is internally developed or commercially available off-the-shelf. If the latter, document the manufacturer and the version. Also, don't forget web-based applications or services when inventorying applications.|
| **Number of work personas**|Work personas are where the three previous efforts converge. You know the departments, the organizational levels within each department, the numbers of applications used by each, respectively, and the type of application. From this information, you want to create a work persona.<br><br>A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc.), within a specific department to a collection of applications used. There's a high probability that you'll have many work personas. These work personas will become units of work, and you'll refer to them in documentation and in meetings. You need to give them a name.<br><br>Give your personas easy and intuitive names like *Amanda - Accounting*, *Mark - Marketing*, or *Sue - Sales*. If the organization levels are common across departments, then decide on a first name that represents the common levels in a department. For example, *Amanda* could be the first name of an individual contributor in any given department, while the first name *Sue* could represent someone from middle management in any given department. Additionally, you can use suffixes (such as *I*, *II*, *Senior*, etc.) to further define departmental structure for a given persona. <br><br>Ultimately, create a naming convention that doesn't require your stakeholders and partners to read through a long list of tables or a secret decoder ring. Also, if possible, try to keep the references as names of people. After all, you're talking about a person who is in that department and who uses that specific software.| | **Number of work personas**|Work personas are where the three previous efforts converge. You know the departments, the organizational levels within each department, the numbers of applications used by each, respectively, and the type of application. From this information, you want to create a work persona.<br><br>A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc.), within a specific department to a collection of applications used. There's a high probability that you have many work personas. These work personas will become units of work, and you refer to them in documentation and in meetings. You need to give them a name.<br><br>Give your personas easy and intuitive names like *Amanda - Accounting*, *Mark - Marketing*, or *Sue - Sales*. If the organization levels are common across departments, then decide on a first name that represents the common levels in a department. For example, *Amanda* could be the first name of an individual contributor in any given department, while the first name *Sue* could represent someone from middle management in any given department. Additionally, you can use suffixes (such as *I*, *II*, *Senior*, etc.) to further define departmental structure for a given persona. <br><br>Ultimately, create a naming convention that doesn't require your stakeholders and partners to read through a long list of tables or a secret decoder ring. Also, if possible, try to keep the references as names of people. After all, you're talking about a person who is in that department and who uses that specific software.|
| **Organization's IT structure**|IT department structures can vary more than the organization. Some IT departments are centralized while others are decentralized. Also, the road to password freedom will probably have you interacting with the *client authentication* team, the *deployment* team, the *security* team, the *PKI* team, the *identity* team, the *cloud* team, etc. Most of these teams will be your partner on your journey to password freedom. Ensure there's a passwordless stakeholder on each of these teams, and that the effort is understood and funded.| | **Organization's IT structure**|IT department structures can vary more than the organization. Some IT departments are centralized while others are decentralized. Also, the road to password freedom will probably have you interacting with the *client authentication* team, the *deployment* team, the *security* team, the *PKI* team, the *identity* team, the *cloud* team, etc. Most of these teams are your partner on your journey to password freedom. Ensure there's a passwordless stakeholder on each of these teams, and that the effort is understood and funded.|
## Assess your organization ## Assess your organization
By now you can understand why this is a journey and not a quick task. You need to investigate user-visible password surfaces for each of your work personas. Once you've identified the password surfaces, you need to mitigate them. Resolving some password surfaces are simple - meaning a solution already exists in the environment and it's only a matter of moving users to it. Resolution to some passwords surfaces may exist, but aren't deployed in your environment. That resolution results in a project that must be planned, tested, and then deployed. That project is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems. Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software development. Even with agile development methodologies, changing the way someone authenticates to an application is critical. Without the proper planning and testing, it has the potential to severely affect productivity. By now you can understand why this is a journey and not a quick task. You need to investigate user-visible password surfaces for each of your work personas. Once you've identified the password surfaces, you need to mitigate them. Resolving some password surfaces are simple - meaning a solution already exists in the environment and it's only a matter of moving users to it. Resolution to some passwords surfaces might exist, but aren't deployed in your environment. That resolution results in a project that must be planned, tested, and then deployed. That project is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems. Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software development. Even with agile development methodologies, changing the way someone authenticates to an application is critical. Without the proper planning and testing, it has the potential to severely affect productivity.
The time to complete the passwordless journey varies, depending on the organizational alignment to a passwordless strategy. Top-down agreement that a passwordless environment is the organization's goal makes conversations much easier. Easier conversations mean less time spent convincing people and more time spent moving toward the goal. Top-down agreement, as a priority within the ranks of other on-going IT projects, helps everyone understand how to prioritize existing projects. Agreeing on priorities should reduce and minimize manager and executive level escalations. After these organizational discussions, modern project management techniques are used to continue the passwordless effort. The organization allocates resources based on the priority (after they've agreed on the strategy). Those resources will: The time to complete the passwordless journey varies, depending on the organizational alignment to a passwordless strategy. Top-down agreement that a passwordless environment is the organization's goal makes conversations easier. Easier conversations mean less time spent convincing people and more time spent moving toward the goal. Top-down agreement, as a priority within the ranks of other on-going IT projects, helps everyone understand how to prioritize existing projects. Agreeing on priorities should reduce and minimize manager and executive level escalations. After these organizational discussions, modern project management techniques are used to continue the passwordless effort. The organization allocates resources based on the priority (after they agreed on the strategy). Those resources will:
- Work through the work personas - Work through the work personas
- Organize and deploy user acceptance testing - Organize and deploy user acceptance testing
@ -90,22 +90,22 @@ The time to complete the passwordless journey varies, depending on the organizat
- Perform user acceptance testing to confirm that the solution mitigates the user visible password surface - Perform user acceptance testing to confirm that the solution mitigates the user visible password surface
- Repeat the testing as needed - Repeat the testing as needed
Your organization's journey to password freedom may take some time. Counting the number of work personas and the number of applications is a good indicator of the investment. Hopefully, your organization is growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go passwordless today is *n*, then it's likely that to go passwordless tomorrow is *n x 2* or more, *n x n*. Don't let the size or duration of the project be a distraction. As you progress through each work persona, the actions and tasks will become more familiar for you and your stakeholders. Scope the project to sizable, realistic phases, pick the correct work personas, and soon you'll see parts of your organization transition to a passwordless state. Your organization's journey to password freedom may take some time. Counting the number of work personas and the number of applications is a good indicator of the investment. Hopefully, your organization is growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go passwordless today is *n*, then it's likely that to go passwordless tomorrow is *n x 2* or more, *n x n*. Don't let the size or duration of the project be a distraction. As you progress through each work persona, the actions and tasks become more familiar for you and your stakeholders. Scope the project to sizable, realistic phases, pick the correct work personas, and soon you'll see parts of your organization transition to a passwordless state.
What's the best guidance for kicking off the journey to password freedom? **You'll want to show your management a proof of concept as soon as possible**. Ideally, you want to show it at each step of your passwordless journey. Keeping your passwordless strategy top of mind and showing consistent progress keeps everyone focused. What's the best guidance for kicking off the journey to password freedom? **You want to show your management a proof of concept as soon as possible**. Ideally, you want to show it at each step of your passwordless journey. Keeping your passwordless strategy top of mind and showing consistent progress keeps everyone focused.
## Work persona ## Work persona
You begin with your work personas. These were part of your preparation process. They have a persona name, such as *Amanda - Accounting II*, or any other naming convention your organization defined. That work persona includes a list of all the applications *Amanda* uses to perform her assigned duties in the accounting department. To start, you need to pick a work persona. It's the targeted work persona you'll enable to complete the journey. You begin with your work personas. These were part of your preparation process. They have a persona name, such as *Amanda - Accounting II*, or any other naming convention your organization defined. That work persona includes a list of all the applications *Amanda* uses to perform her assigned duties in the accounting department. To start, you need to pick a work persona. It's the targeted work persona you enable to complete the journey.
> [!TIP] > [!TIP]
> Avoid using any work personas from your IT department. This method is probably the worst way to start the passwordless journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas for the middle or end of your journey. > Avoid using any work personas from your IT department. This method is probably the worst way to start the passwordless journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas for the middle or end of your journey.
Review your collection of work personas. Early in your passwordless journey, identify personas with the fewest applications. These work personas could represent an entire department or two. These roles are the perfect work personas for your proof-of-concept (POC) or pilot. Review your collection of work personas. Early in your passwordless journey, identify personas with the fewest applications. These work personas could represent an entire department or two. These roles are the perfect work personas for your proof-of-concept (POC) or pilot.
Most organizations host their POC in a test lab or environment. If you do that test with a password-free strategy, it may be more challenging and take more time. To test in a lab, you must first duplicate the environment of the targeted persona. This process could take a few days or several weeks, depending on the complexity of the targeted work persona. Most organizations host their POC in a test lab or environment. If you do that test with a password-free strategy, it might be more challenging and take more time. To test in a lab, you must first duplicate the environment of the targeted persona. This process could take a few days or several weeks, depending on the complexity of the targeted work persona.
You'll want to balance lab testing with providing results to management quickly. Continuing to show forward progress on your journey to password freedom is always a good thing. If there are ways you can test in production with low or no risk, it may be advantageous to your timeline. You want to balance lab testing with providing results to management quickly. Continuing to show forward progress on your journey to password freedom is always a good thing. If there are ways you can test in production with low or no risk, it might be advantageous to your timeline.
The journey to password freedom is to take each work persona through each step of the process. In the beginning, we encourage working with one persona at a time to ensure team members and stakeholders are familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel as resources allow. The process looks something like this: The journey to password freedom is to take each work persona through each step of the process. In the beginning, we encourage working with one persona at a time to ensure team members and stakeholders are familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel as resources allow. The process looks something like this:

View File

@ -1,11 +1,11 @@
--- ---
title: Deploy a passwordless a replacement option title: Deploy a passwordless replacement option
description: Learn about how to deploy a passwordless a replacement option, the first step of the Microsoft passwordless journey. description: Learn about how to deploy a passwordless replacement option, the first step of the Microsoft passwordless journey.
ms.topic: concept-article ms.topic: concept-article
ms.date: 12/13/2023 ms.date: 01/29/2024
--- ---
# Deploy a passwordless a replacement option # Deploy a passwordless replacement option
:::row::: :::row:::
:::column span="1"::: :::column span="1":::
@ -29,11 +29,11 @@ Both options provide a strong, two-factor authentication to Microsoft Entra ID a
## Identify test users representing the targeted work persona ## Identify test users representing the targeted work persona
A successful transition relies on user acceptance testing. It's impossible for you to know how every work persona goes about their day-to-day activities, or how to accurately validate them. You need to enlist the help of users who fit the targeted work persona. You only need a few users from the targeted work persona. As you cycle through step 2, you may want to change a few of the users (or add a few) as part of your validation process. A successful transition relies on user acceptance testing. It's impossible for you to know how every work persona goes about their day-to-day activities, or how to accurately validate them. You need to enlist the help of users who fit the targeted work persona. You only need a few users from the targeted work persona. As you cycle through step 2, you might want to change a few of the users (or add a few) as part of your validation process.
## Deploy Windows Hello for Business or FIDO2 security keys to test users ## Deploy Windows Hello for Business or FIDO2 security keys to test users
Next, you'll want to plan your password replacement deployment. Your test users will need an alternative way to sign-in during step 2 of the journey to becoming passwordless. Use the [Windows Hello for Business planning guide](..\hello-for-business\deploy\index.md) to help learning which deployment is best suited for your environment. Next, use one of the deployment guides to deploy Windows Hello for Business. With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment. Next, you want to plan your password replacement deployment. Your test users need an alternative way to sign-in during step 2 of the journey to becoming passwordless. Use the [Windows Hello for Business planning guide](..\hello-for-business\deploy\index.md) to help learning which deployment is best suited for your environment. Next, use one of the deployment guides to deploy Windows Hello for Business. With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You use the first work persona to validate your Windows Hello for Business deployment.
If you decide to use FIDO2 security keys, follow the [Enable security key sign-in to Windows guide](/entra/identity/authentication/howto-authentication-passwordless-security-key-windows) to learn how to adopt FIDO2 security keys. If you decide to use FIDO2 security keys, follow the [Enable security key sign-in to Windows guide](/entra/identity/authentication/howto-authentication-passwordless-security-key-windows) to learn how to adopt FIDO2 security keys.
@ -42,7 +42,7 @@ If you decide to use FIDO2 security keys, follow the [Enable security key sign-i
## Validate passwords and Windows Hello for Business or FIDO2 security keys ## Validate passwords and Windows Hello for Business or FIDO2 security keys
In this first step, passwords and your password replacement choice must coexist. You want to validate that while your targeted work personas can sign in and unlock using Windows Hello for Business or security keys, but they can also sign-in, unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create frustration and confusion with your targeted user personas. In this first step, passwords and your password replacement choice must coexist. You want to validate all scenarios while the targeted work personas can sign in and unlock using Windows Hello or security keys. Users can also sign-in, unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create frustration and confusion with your targeted user personas.
:::image type="content" source="images/lock-screen.png" alt-text="Screenshot of the Windows lock screen showing the fingerprint, PIN and password credential providers." border="false"::: :::image type="content" source="images/lock-screen.png" alt-text="Screenshot of the Windows lock screen showing the fingerprint, PIN and password credential providers." border="false":::

View File

@ -2,7 +2,7 @@
title: Reduce the user-visible password surface area title: Reduce the user-visible password surface area
description: Learn about how to reduce the user-visible password surface area, the second step of the Microsoft passwordless journey. description: Learn about how to reduce the user-visible password surface area, the second step of the Microsoft passwordless journey.
ms.topic: concept-article ms.topic: concept-article
ms.date: 01/26/2024 ms.date: 01/29/2024
--- ---
# Reduce the user-visible password surface area # Reduce the user-visible password surface area
@ -34,35 +34,35 @@ Now is the time to learn more about the targeted work persona. You should have a
| **🔲** | *How frequently do you use the application in a given day or week?* | | **🔲** | *How frequently do you use the application in a given day or week?* |
| **🔲** | *Is the password you type into the application the same as the password you use to sign-in to Windows?* | | **🔲** | *Is the password you type into the application the same as the password you use to sign-in to Windows?* |
Some organizations will empower their users to write this information while some may insist on having a member of the IT department shadow them. An objective viewer may notice a password prompt that the user overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could miss one password prompt that could delay the transition to being passwordless. Some organizations empower their users to write this information, while some might insist on having a member of the IT department shadow them. An objective viewer might notice a password prompt that the user overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could miss one password prompt that could delay the transition to being passwordless.
## Identify password usage and plan, develop, and deploy password mitigations ## Identify password usage and plan, develop, and deploy password mitigations
Your test users have provided you valuable information that describes how, what, why, and when they use a password. It's now time for your team to identify each of these password use cases and understand why the user must use a password.\ Your test users provided you valuable with information that describes how, what, why, and when they use a password. It's now time for your team to identify each of these password use cases and understand why the user must use a password.\
Create a list of the scenarios. Each scenario should have a clear problem statement. Name the scenario with a one-sentence summary of the problem statement. Include in the scenario the results of your team's investigation as to why the ser is prompted by a password. Include relevant, but accurate details. If it's policy or procedure driven, then include the name and section of the policy that dictates why the workflow uses a password. Create a list of the scenarios. Each scenario should have a clear problem statement. Name the scenario with a one-sentence summary of the problem statement. Include in the scenario the results of your team's investigation as to why the user is asked to provide a password. Include relevant, but accurate details. If the scenario is policy or procedure-driven, then include the name and section of the policy that dictates why the workflow uses a password.
Keep in mind your test users won't uncover all scenarios. Some scenarios you'll need to force on your users because they're low percentage scenarios. Remember to include the following scenarios: Your test users won't uncover all scenarios, therefore you must force on some uncommon scenarios. Remember to include the following:
- Provisioning a new brand new user without a password - Provision a new user without a password
- Users who forget the PIN or other remediation flows when the strong credential is unusable - Users who forget the PIN or other remediation flows when the strong credential is unusable
Next, review your list of scenarios. You can start with the workflows that are dictated by process or policy, or you can begin with workflows that need technical solutions, whichever of the two is easier or quicker. This choice varies by organization. Next, review your list of scenarios. You can start with the workflows that are dictated by process or policy, or you can begin with workflows that need technical solutions, whichever of the two is easier or quicker. This choice varies by organization.
Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation as a solution to your scenario. Don't worry about the implementation details for the solution. An overview of the changes needed to educe the password usages is all you need. If there are technical changes needed, either infrastructure or code changes, the exact details will likely be included in the project documentation. However your organization tracks projects, create a new project in that system. Associate your scenario to that project and start the processes needed to get that project funded. Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation as a solution to your scenario. Don't worry about the implementation details for the solution. An overview of the changes needed to reduce the password usages is all you need. If there are technical changes needed, either infrastructure or code changes, the exact details are likely included in the project documentation. However your organization tracks projects, create a new project in that system. Associate your scenario to that project and start the processes needed to get that project funded.
Mitigating password usage with applications is one of the more challenging obstacles in the passwordless journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS). Mitigating password usage with applications is one of the more challenging obstacles in the passwordless journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS).
The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Microsoft Entra identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases. The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Microsoft Entra identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to integrate in your Microsoft Entra ID tenant, use federated identities, or use Windows integrated authentication. Work with third-party software vendors to update their software to integrate in Microsoft Entra ID, support federated identities, or use Windows integrated authentication. Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to integrate in your Microsoft Entra ID tenant, use federated identities, or use Windows integrated authentication. Work with third-party software publishers to update their software to integrate in Microsoft Entra ID, support federated identities, or use Windows integrated authentication.
## Repeat until all user password usage is mitigated ## Repeat until all user password usage is mitigated
Some or all of your mitigations are in place. You need to validate that your solutions have solved their problem statements. This stage is where you rely on your test users. You want to keep a good portion of your first test users, but this point is a good opportunity to replace or add a few. Survey test users workflow for password usage. If all goes well, you've closed most or all of the gaps. A few are likely to remain. Evaluate your solutions and what went wrong, change your solution as needed until you reach a solution that removes your user's need to type a password. If you're stuck, others might be too. Use the forums from various sources or your network of IT colleagues to describe your problem and see how others are solving it. If you're out of options, contact Microsoft for assistance. Some or all of your mitigations are in place. You need to validate that your solutions solved their problem statements. This stage is where you rely on your test users. You want to keep a good portion of your first test users, but this point is a good opportunity to replace or add a few. Survey test users workflow for password usage. If all goes well, you closed most or all of the gaps. A few are likely to remain. Evaluate your solutions and what went wrong, change your solution as needed until you reach a solution that removes your user's need to type a password. If you're stuck, others might be too. Use the forums from various sources or your network of IT colleagues to describe your problem and see how others are solving it. If you're out of options, contact Microsoft for assistance.
## Remove password capabilities from Windows ## Remove password capabilities from Windows
You believe you've mitigated all the password usage for the targeted work persona. Now comes the true test: configure Windows so the user can't use a password.\ You believe you mitigated all the password usage for the targeted work persona. Now comes the true test: configure Windows so the user can't use a password.\
Windows offers three main options to reduce or eliminate the password surface area: Windows offers three main options to reduce or eliminate the password surface area:
- Windows passwordless experience - Windows passwordless experience
@ -71,7 +71,7 @@ Windows offers three main options to reduce or eliminate the password surface ar
### Windows passwordless experience ### Windows passwordless experience
*Windows Passwordless experience* is a security policy that hides the password credential provider for user accounts that sign in with Windows Hello or a FIDO2 security key. This is the recommended option, but it's only available on Microsoft Entra joined devices. The following image shows the Windows lock screen when Windows passwordless experience is enabled. A user enrolled in Windows Hello for Business doesn't have the option to use a password to sign in: *Windows Passwordless experience* is a security policy that hides the password credential provider for user accounts that sign in with Windows Hello or a FIDO2 security key. Windows Passwordless experience is the recommended option, but it's only available on Microsoft Entra joined devices. The following image shows the Windows lock screen when Windows passwordless experience is enabled. A user enrolled in Windows Hello for Business doesn't have the option to use a password to sign in:
:::image type="content" source="images/passwordless-experience.png" alt-text="Screenshot of the Windows lock screen with passwordless experience enabled." border="false"::: :::image type="content" source="images/passwordless-experience.png" alt-text="Screenshot of the Windows lock screen with passwordless experience enabled." border="false":::
@ -79,7 +79,7 @@ To learn more, see [Windows passwordless experience](../passwordless-experience/
### Exclude the password credential provider ### Exclude the password credential provider
The *Exclude credential providers* policy setting can be used to disable the password credentail provider. When configured, Windows disables the possibility to uyse passwords for *all accounts*, including local accounts. It also prevents the use of passwords for RDP and *Run as* authentication scenarios. This policy setting might impact support scenarios, such as when a user needs to sign in with a local account to troubleshoot a problem. For this reason, carefully evaluate all scenarios before enabling it. The *Exclude credential providers* policy setting can be used to disable the password credential provider. When configured, Windows disables the possibility to use passwords for *all accounts*, including local accounts. It also prevents the use of passwords for RDP and *Run as* authentication scenarios. This policy setting might impact support scenarios, such as when a user needs to sign in with a local account to troubleshoot a problem. For this reason, carefully evaluate all scenarios before you enable the setting.
- GPO: **Computer Configuration** > **Administrative Templates** > **System** > **Logon** > **Exclude credential providers** - GPO: **Computer Configuration** > **Administrative Templates** > **System** > **Logon** > **Exclude credential providers**
- CSP: `./Device/Vendor/MSFT/Policy/Config/ADMX_CredentialProviders/`[ExcludedCredentialProviders](/windows/client-management/mdm/policy-csp-admx-credentialproviders#excludedcredentialproviders) - CSP: `./Device/Vendor/MSFT/Policy/Config/ADMX_CredentialProviders/`[ExcludedCredentialProviders](/windows/client-management/mdm/policy-csp-admx-credentialproviders#excludedcredentialproviders)
@ -88,14 +88,14 @@ The value to enter in the policy to hide the password credential provider is `{6
### Require Windows Hello for Business or a smart card ### Require Windows Hello for Business or a smart card
The *Require Windows Hello for Business or a smart card* policy setting can be used to require Windows Hello for Business or a smart card for interactive logon. When enabled, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card. Before enabling this policy, the user must be enrolled in Windows Hello for Business or have a smart card. Therefore, implementing this policy requires careful planning and coordination. The *Require Windows Hello for Business or a smart card* policy setting can be used to require Windows Hello for Business or a smart card for interactive logon. When enabled, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card. Before you enable this policy setting, the user must be enrolled in Windows Hello for Business or have a smart card. Therefore, implementing this policy requires careful planning and coordination.
- GPO: **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** > **Interactive logon: Require Windows Hello for Business or smart card** - GPO: **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** > **Interactive logon: Require Windows Hello for Business or smart card**
- CSP: not available - CSP: not available
## Validate that none of the workflows needs passwords ## Validate that none of the workflows needs passwords
This stage is the significant moment. You have identified password usage, developed solutions to mitigate password usage, and have removed or disabled password usage from Windows. In this configuration, your users won't be able to use a password. Users will be blocked if any of their workflows ask them for a password. Ideally, your test users should be able to complete all the work flows of the targeted work persona without any password usage. Don't forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN or can't use their strong credential. Ensure those scenarios are validated as well. This stage is the significant moment. You identified password usage, developed solutions to mitigate password usage, and removed or disabled password usage from Windows. In this configuration, your users can't use a password. Users are blocked if any of their workflows ask them for a password. Ideally, your test users should be able to complete all the work flows of the targeted work persona without any password usage. Don't forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN or can't use their strong credential. Ensure those scenarios are validated as well.
## Next steps ## Next steps

View File

@ -2,7 +2,7 @@
title: Transition into a passwordless deployment title: Transition into a passwordless deployment
description: Learn about how to transition into a passwordless deployment, the third step of the Microsoft passwordless journey. description: Learn about how to transition into a passwordless deployment, the third step of the Microsoft passwordless journey.
ms.topic: concept-article ms.topic: concept-article
ms.date: 12/13/2023 ms.date: 01/29/2024
--- ---
# Transition into a passwordless deployment # Transition into a passwordless deployment
@ -33,11 +33,11 @@ An awareness campaign introduces the users to the new way of authenticating to t
## Include remaining users that fit the work persona ## Include remaining users that fit the work persona
You've implemented the awareness campaign for the targeted users. These users are informed and ready to transition to being passwordless. Add the remaining users that match the targeted work persona to your deployment. You implemented the awareness campaign for the targeted users. These users are informed and ready to transition to being passwordless. Add the remaining users that match the targeted work persona to your deployment.
## Validate that none of the users of the work personas need passwords ## Validate that none of the users of the work personas need passwords
You've successfully transitioned all users for the targeted work persona to being passwordless. Monitor the users within the work persona to ensure they don't encounter any issues while working in a passwordless environment. You successfully transitioned all users for the targeted work persona to being passwordless. Monitor the users within the work persona to ensure they don't encounter any issues while working in a passwordless environment.
Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues appropriately. As you triage issues, consider the following questions: Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues appropriately. As you triage issues, consider the following questions:
@ -48,13 +48,13 @@ Track all reported issues. Set priority and severity to each reported issue and
| **🔲** | *Is the outage a result of a misconfiguration?* | | **🔲** | *Is the outage a result of a misconfiguration?* |
| **🔲** | *Is the outage an overlooked gap from step 2?* | | **🔲** | *Is the outage an overlooked gap from step 2?* |
Each organization's priority and severity will differ. However, most organizations consider work stoppages to be fairly significant. Your team should predefine levels of priority and severity. With each of these levels, create service level agreements (SLAs) for each combination of severity and priority, and hold everyone accountable to those agreements. Reactive planning enables people to spend more time on the issue and resolving it, and less time on the process. Each organization's priority and severity differ. However, most organizations consider work stoppages to be fairly significant. Your team should predefine levels of priority and severity. With each of these levels, create service level agreements (SLAs) for each combination of severity and priority, and hold everyone accountable to those agreements. Reactive planning enables people to spend more time on the issue and resolving it, and less time on the process.
Resolve the issues per your service level agreements. Higher severity items may require returning some or all of the user's password surface. Clearly this outcome isn't the end goal, but don't let it slow down your momentum towards becoming passwordless. Refer to how you reduced the user's password surface in step 2 and progress forward to a solution, deploying that solution and validating it. Resolve the issues per your service level agreements. Higher severity items might require returning some or all of the user's password surface. Clearly this outcome isn't the end goal, but don't let it slow down your momentum towards becoming passwordless. Refer to how you reduced the user's password surface in step 2, and progress forward to a solution, deploying that solution and validating it.
## Configure user accounts to prevent password authentication ## Configure user accounts to prevent password authentication
You transitioned all the users for the targeted work persona to a passwordless environment and you've successfully validated all their workflows. The last step to complete the passwordless transition is to remove the user's knowledge of the password. You transitioned all the users for the targeted work persona to a passwordless environment and validated all their workflows. The last step to complete the passwordless transition is to remove the user's knowledge of the password.
### Password scrambling ### Password scrambling
@ -63,7 +63,7 @@ While you can't completely remove the password from the user's account, you can
> [!TIP] > [!TIP]
> Enable [Microsoft Entra self-service password reset (SSPR)](/entra/identity/authentication/tutorial-enable-sspr) to allow the users to reset their password. Once implemented, users can sign in to their Windows devices using Windows Hello for Business or a FIDO2 security key, and reset their password from https://aka.ms/sspr. Combine it with [password writeback](/entra/identity/authentication/tutorial-enable-cloud-sync-sspr-writeback) to have the password reset synchronized to your on-premises Active Directory. > Enable [Microsoft Entra self-service password reset (SSPR)](/entra/identity/authentication/tutorial-enable-sspr) to allow the users to reset their password. Once implemented, users can sign in to their Windows devices using Windows Hello for Business or a FIDO2 security key, and reset their password from https://aka.ms/sspr. Combine it with [password writeback](/entra/identity/authentication/tutorial-enable-cloud-sync-sspr-writeback) to have the password reset synchronized to your on-premises Active Directory.
The following sample PowerShell script generates a random password of 64 characters and sets it for the user specified in the variable name $userId agains Microsoft Entra ID. The following sample PowerShell script generates a random password of 64 characters and sets it for the user specified in the variable name $userId against Microsoft Entra ID.
Modify the **userId** variable of the script to match your environment (first line), and then run it in a PowerShell session. When prompted to authenticate to Microsoft Entra ID, use the credentials of an account with a role capable of resetting passwords. Modify the **userId** variable of the script to match your environment (first line), and then run it in a PowerShell session. When prompted to authenticate to Microsoft Entra ID, use the credentials of an account with a role capable of resetting passwords.
```azurepowershell-interactive ```azurepowershell-interactive
@ -127,8 +127,8 @@ If your organizational policies allow it, you can configure the randomized passw
### Password rotation ### Password rotation
Consider implementing automation to rotate the user's password on a regular basis. This approach ensures that the user's password is always randomized and prevents the user from knowing the password. Consider implementing automation to rotate the user's password regularly. This approach ensures that the user's password is always randomized and prevents the user from knowing the password.
## Next steps ## Next steps
Microsoft is working hard to make the passwordless journey easier for you. We're working on new features and capabilities to help you transition to a passwordless environment, and to achieves the long-term security promise of a truly passwordless environment. Check back often to see what's new. Microsoft is working hard to make the passwordless journey easier for you. We're working on new features and capabilities to help you transition to a passwordless environment, and to achieve the long-term security promise of a truly passwordless environment. Check back often to see what's new.