From f976a899b7346434776ad926bb69733483ffc880 Mon Sep 17 00:00:00 2001 From: tiburd Date: Wed, 11 Nov 2020 07:52:00 -0800 Subject: [PATCH] Edit pass: Acrolinx fixes --- ...nced-troubleshooting-802-authentication.md | 47 ++++---- .../manage-settings-app-with-group-policy.md | 8 +- .../mdm/esim-enterprise-management.md | 10 +- .../troubleshoot-inaccessible-boot-device.md | 114 +++++++++--------- .../troubleshoot-tcpip-connectivity.md | 34 +++--- .../auditing/audit-detailed-file-share.md | 6 +- .../auditing/audit-group-membership.md | 15 ++- .../auditing/audit-logoff.md | 10 +- .../audit-non-sensitive-privilege-use.md | 8 +- 9 files changed, 128 insertions(+), 124 deletions(-) diff --git a/windows/client-management/advanced-troubleshooting-802-authentication.md b/windows/client-management/advanced-troubleshooting-802-authentication.md index 4af9868736..c27a78fa4c 100644 --- a/windows/client-management/advanced-troubleshooting-802-authentication.md +++ b/windows/client-management/advanced-troubleshooting-802-authentication.md @@ -17,17 +17,17 @@ ms.topic: troubleshooting ## Overview -This is a general troubleshooting of 802.1X wireless and wired clients. With 802.1X and wireless troubleshooting, it's important to know how the flow of authentication works, and then figuring out where it's breaking. It involves a lot of third party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. Since we don't make access points or switches, it won't be an end-to-end Microsoft solution. +This article includes general troubleshooting for 802.1X wireless and wired clients. While troubleshooting 802.1X and wireless, it's important to know how the flow of authentication works, and then figure out where it's breaking. It involves a lot of third-party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. We don't make access points or switches, so it's not an end-to-end Microsoft solution. ## Scenarios -This troubleshooting technique applies to any scenario in which wireless or wired connections with 802.1X authentication is attempted and then fails to establish. The workflow covers Windows 7 - 10 for clients, and Windows Server 2008 R2 - 2012 R2 for NPS. +This troubleshooting technique applies to any scenario in which wireless or wired connections with 802.1X authentication is attempted and then fails to establish. The workflow covers Windows 7 through Windows 10 for clients, and Windows Server 2008 R2 through Windows Server 2012 R2 for NPS. -## Known Issues +## Known issues None -## Data Collection +## Data collection See [Advanced troubleshooting 802.1X authentication data collection](data-collection-for-802-authentication.md). @@ -35,11 +35,11 @@ See [Advanced troubleshooting 802.1X authentication data collection](data-collec Viewing [NPS authentication status events](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc735320(v%3dws.10)) in the Windows Security [event log](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc722404(v%3dws.11)) is one of the most useful troubleshooting methods to obtain information about failed authentications. -NPS event log entries contain information on the connection attempt, including the name of the connection request policy that matched the connection attempt and the network policy that accepted or rejected the connection attempt. If you are not seeing both success and failure events, see the section below on [NPS audit policy](#audit-policy). +NPS event log entries contain information about the connection attempt, including the name of the connection request policy that matched the connection attempt and the network policy that accepted or rejected the connection attempt. If you don't see both success and failure events, see the [NPS audit policy](#audit-policy) section later in this article. -Check Windows Security Event log on the NPS Server for NPS events corresponding to rejected ([event ID 6273](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc735399(v%3dws.10))) or accepted ([event ID 6272](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc735388(v%3dws.10))) connection attempts. +Check Windows Security Event log on the NPS Server for NPS events that correspond to rejected ([event ID 6273](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc735399(v%3dws.10))) or accepted ([event ID 6272](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc735388(v%3dws.10))) connection attempts. -In the event message, scroll to the very bottom, and check the [Reason Code](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197570(v%3dws.10)) field and the text associated with it. +In the event message, scroll to the very bottom, and then check the [Reason Code](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197570(v%3dws.10)) field and the text that's associated with it. ![example of an audit failure](images/auditfailure.png) *Example: event ID 6273 (Audit Failure)*

@@ -47,35 +47,35 @@ In the event message, scroll to the very bottom, and check the [Reason Code](htt ![example of an audit success](images/auditsuccess.png) *Example: event ID 6272 (Audit Success)*
-‎The WLAN AutoConfig operational log lists information and error events based on conditions detected by or reported to the WLAN AutoConfig service. The operational log contains information about the wireless network adapter, the properties of the wireless connection profile, the specified network authentication, and, in the event of connectivity problems, the reason for the failure. For wired network access, Wired AutoConfig operational log is equivalent one. +‎The WLAN AutoConfig operational log lists information and error events based on conditions detected by or reported to the WLAN AutoConfig service. The operational log contains information about the wireless network adapter, the properties of the wireless connection profile, the specified network authentication, and, in the event of connectivity problems, the reason for the failure. For wired network access, the Wired AutoConfig operational log is an equivalent one. -On the client side, navigate to **Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\WLAN-AutoConfig/Operational** for wireless issues. For wired network access issues, navigate to **..\Wired-AutoConfig/Operational**. See the following example: +On the client side, go to **Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\WLAN-AutoConfig/Operational** for wireless issues. For wired network access issues, go to **..\Wired-AutoConfig/Operational**. See the following example: ![event viewer screenshot showing wired-autoconfig and WLAN autoconfig](images/eventviewer.png) -Most 802.1X authentication issues are due to problems with the certificate that is used for client or server authentication (e.g. invalid certificate, expiration, chain verification failure, revocation check failure, etc.). +Most 802.1X authentication issues are because of problems with the certificate that's used for client or server authentication. Examples include invalid certificate, expiration, chain verification failure, and revocation check failure. -First, validate the type of EAP method being used: +First, validate the type of EAP method that's used: ![eap authentication type comparison](images/comparisontable.png) -If a certificate is used for its authentication method, check if the certificate is valid. For server (NPS) side, you can confirm what certificate is being used from the EAP property menu. In **NPS snap-in**, go to **Policies** > **Network Policies**. Right click on the policy and select **Properties**. In the pop-up window, go to the **Constraints** tab and select the **Authentication Methods** section. +If a certificate is used for its authentication method, check whether the certificate is valid. For the server (NPS) side, you can confirm what certificate is being used from the EAP property menu. In **NPS snap-in**, go to **Policies** > **Network Policies**. Select and hold (or right-click) the policy, and then select **Properties**. In the pop-up window, go to the **Constraints** tab, and then select the **Authentication Methods** section. ![Constraints tab of the secure wireless connections properties](images/eappropertymenu.png) -The CAPI2 event log will be useful for troubleshooting certificate-related issues. -This log is not enabled by default. You can enable this log by expanding **Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\CAPI2**, right-clicking **Operational** and then clicking **Enable Log**. +The CAPI2 event log is useful for troubleshooting certificate-related issues. +By default, this log isn't enabled. To enable this log, expand **Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\CAPI2**, select and hold (or right-click) **Operational**, and then select **Enable Log**. ![screenshot of event viewer](images/capi.png) -The following article explains how to analyze CAPI2 event logs: +For information about how to analyze CAPI2 event logs, see [Troubleshooting PKI Problems on Windows Vista](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-vista/cc749296%28v=ws.10%29). -When troubleshooting complex 802.1X authentication issues, it is important to understand the 802.1X authentication process. The following figure is an example of wireless connection process with 802.1X authentication: +When troubleshooting complex 802.1X authentication issues, it's important to understand the 802.1X authentication process. Here's an example of wireless connection process with 802.1X authentication: ![authenticator flow chart](images/authenticator_flow_chart.png) -If you [collect a network packet capture](troubleshoot-tcpip-netmon.md) on both the client and the server (NPS) side, you can see a flow like the one below. Type **EAPOL** in the Display Filter in for a client side capture, and **EAP** for an NPS side capture. See the following examples: +If you [collect a network packet capture](troubleshoot-tcpip-netmon.md) on both the client and the server (NPS) side, you can see a flow like the one below. Type **EAPOL** in the Display Filter for a client-side capture, and **EAP** for an NPS-side capture. See the following examples: ![client-side packet capture data](images/clientsidepacket_cap_data.png) *Client-side packet capture data*

@@ -85,16 +85,16 @@ If you [collect a network packet capture](troubleshoot-tcpip-netmon.md) on both ‎ > [!NOTE] -> If you have a wireless trace, you can also [view ETL files with network monitor](https://docs.microsoft.com/windows/desktop/ndf/using-network-monitor-to-view-etl-files) and apply the **ONEX_MicrosoftWindowsOneX** and **WLAN_MicrosoftWindowsWLANAutoConfig** Network Monitor filters. Follow the instructions under the **Help** menu in Network Monitor to load the reqired [parser](https://blogs.technet.microsoft.com/netmon/2010/06/04/parser-profiles-in-network-monitor-3-4/) if needed. See the example below. +> If you have a wireless trace, you can also [view ETL files with network monitor](https://docs.microsoft.com/windows/desktop/ndf/using-network-monitor-to-view-etl-files) and apply the **ONEX_MicrosoftWindowsOneX** and **WLAN_MicrosoftWindowsWLANAutoConfig** Network Monitor filters. If you need to load the required [parser](https://blogs.technet.microsoft.com/netmon/2010/06/04/parser-profiles-in-network-monitor-3-4/), see the instructions under the **Help** menu in Network Monitor. Here's an example: ![ETL parse](images/etl.png) ## Audit policy -NPS audit policy (event logging) for connection success and failure is enabled by default. If you find that one or both types of logging are disabled, use the following steps to troubleshoot. +By default, NPS audit policy (event logging) for connection success and failure is enabled. If you find that one or both types of logging are disabled, use the following steps to troubleshoot. View the current audit policy settings by running the following command on the NPS server: -``` +```console auditpol /get /subcategory:"Network Policy Server" ``` @@ -106,13 +106,12 @@ Logon/Logoff Network Policy Server Success and Failure -If it shows ‘No auditing’, you can run this command to enable it: - -``` +If it says, "No auditing," you can run this command to enable it: +```console auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable ``` -Even if audit policy appears to be fully enabled, it sometimes helps to disable and then re-enable this setting. You can also enable Network Policy Server logon/logoff auditing via Group Policy. The success/failure setting can be found under **Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff -> Audit Network Policy Server**. +Even if audit policy appears to be fully enabled, it sometimes helps to disable and then re-enable this setting. You can also enable Network Policy Server logon/logoff auditing by using Group Policy. To get to the success/failure setting, select **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Advanced Audit Policy Configuration** > **Audit Policies** > **Logon/Logoff** > **Audit Network Policy Server**. ## Additional references diff --git a/windows/client-management/manage-settings-app-with-group-policy.md b/windows/client-management/manage-settings-app-with-group-policy.md index dc31960057..2950a6c6d9 100644 --- a/windows/client-management/manage-settings-app-with-group-policy.md +++ b/windows/client-management/manage-settings-app-with-group-policy.md @@ -19,13 +19,13 @@ ms.topic: article - Windows 10, Windows Server 2016 -You can now manage the pages that are shown in the Settings app by using Group Policy. This lets you hide specific pages from users. Before Windows 10, version 1703, you could either show everything in the Settings app or hide it completely. -To make use of the Settings App group polices on Windows server 2016, install fix [4457127](https://support.microsoft.com/help/4457127/windows-10-update-kb4457127) or a later cumulative update. +You can now manage the pages that are shown in the Settings app by using Group Policy. When you use Group Policy to manage pages, you can hide specific pages from users. Before Windows 10, version 1703, you could either show everything in the Settings app or hide it completely. +To make use of the Settings App group policies on Windows server 2016, install fix [4457127](https://support.microsoft.com/help/4457127/windows-10-update-kb4457127) or a later cumulative update. >[!Note] >Each server that you want to manage access to the Settings App must be patched. -To centrally manage the new policies copy the ControlPanel.admx and ControlPanel.adml file to [Central Store](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) if your company uses one or the PolicyDefinitions folder of the Domain Controllers used for Group Policy management. +If your company uses one or the PolicyDefinitions folder of the Domain Controllers used for Group Policy management, to centrally manage the new policies, copy the ControlPanel.admx and ControlPanel.adml file to [Central Store](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra). This policy is available for both User and Computer depending on the version of the OS. Windows Server 2016 with KB 4457127 applied will have both User and Computer policy. Windows 10, version 1703, added Computer policy for the Settings app. Windows 10, version 1809, added User policy for the Settings app. @@ -39,7 +39,7 @@ Policy paths: ## Configuring the Group Policy -The Group Policy can be configured in one of two ways: specify a list of pages that are shown or specify a list of pages to hide. To do this, add either **ShowOnly:** or **Hide:** followed by a semicolon delimited list of URIs in **Settings Page Visiblity**. For a full list of URIs, see the URI scheme reference section in [Launch the Windows Settings app](https://docs.microsoft.com/windows/uwp/launch-resume/launch-settings-app#ms-settings-uri-scheme-reference). +The Group Policy can be configured in one of two ways: specify a list of pages that are shown or specify a list of pages to hide. To do this, add either **ShowOnly:** or **Hide:** followed by a semicolon-delimited list of URIs in **Settings Page Visibility**. For a full list of URIs, see the URI scheme reference section in [Launch the Windows Settings app](https://docs.microsoft.com/windows/uwp/launch-resume/launch-settings-app#ms-settings-uri-scheme-reference). >[!NOTE] > When you specify the URI in the Settings Page Visibility textbox, don't include **ms-settings:** in the string. diff --git a/windows/client-management/mdm/esim-enterprise-management.md b/windows/client-management/mdm/esim-enterprise-management.md index 79545b45cc..43f44a4d2a 100644 --- a/windows/client-management/mdm/esim-enterprise-management.md +++ b/windows/client-management/mdm/esim-enterprise-management.md @@ -12,15 +12,15 @@ ms.topic: conceptual --- # How Mobile Device Management Providers support eSIM Management on Windows -The eSIM Profile Management Solution puts the Mobile Device Management (MDM) Provider in the front and center. The whole idea is to leverage an already existing solution that customers are familiar with and that they use to manage devices. The expectations from an MDM are that it will leverage the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and be able to use Groups and Users the same way. This way, the eSIM profile download and installation happens on the background and not impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/de-assignment, etc.) the same way as they currently do device management. - If you are a Mobile Device Management (MDM) Provider and would like to support eSIM Management on Windows, you should do the following: +The eSIM Profile Management Solution puts the Mobile Device Management (MDM) Provider in the front and center. The whole idea is to use an already existing solution that customers are familiar with and that they use to manage devices. The expectations from an MDM are that it will use the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and be able to use Groups and Users the same way. This way, the eSIM profile download and the installation happen in the background without impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/de-assignment, etc.) the same way as they currently do device management. + If you are a Mobile Device Management (MDM) Provider and want to support eSIM Management on Windows, perform the following steps: - Onboard to Azure Active Directory -- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, please contact them and learn more about their onboarding. If you would like to support multiple mobile operators, [orchestrator providers]( https://www.idemia.com/esim-management-facilitation) are there to act as a proxy that will handle MDM onboarding as well as mobile operator onboarding. Their main [role]( https://www.idemia.com/smart-connect-hub) is to enable the process to be as painless but scalable to all parties. +- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows doesn't limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, contact them and learn more about their onboarding. If you want to support multiple mobile operators, [orchestrator providers]( https://www.idemia.com/esim-management-facilitation) are there to act as a proxy that will handle MDM onboarding as well as mobile operator onboarding. Their main [role]( https://www.idemia.com/smart-connect-hub) is to enable the process to be as painless but scalable to all parties. - Assess solution type that you would like to provide your customers - Batch/offline solution - IT Admin can manually import a flat file containing list of eSIM activation codes, and provision eSIM on LTE enabled devices. -- Operator does not have visibility over status of the eSIM profiles and device eSIM has been downloaded and installed to +- Operator doesn't have visibility over status of the eSIM profiles and device eSIM has been downloaded and installed to - Real-time solution - MDM automatically syncs with the Operator backend system for subscription pool and eSIM management, via sim vendor solution component. IT Admin can view subscription pool and provision eSIM in real time. - Operator is notified of the status of each eSIM profile and has visibility on which devices are being used -**Note:** The solution type is not noticeable to the end-user. The choice between the two is made between the MDM and the Mobile Operator. +**Note:** End users don't notice the solution type. The choice between the two is made between the MDM and the Mobile Operator. diff --git a/windows/client-management/troubleshoot-inaccessible-boot-device.md b/windows/client-management/troubleshoot-inaccessible-boot-device.md index 0bdc744338..bdb67e2528 100644 --- a/windows/client-management/troubleshoot-inaccessible-boot-device.md +++ b/windows/client-management/troubleshoot-inaccessible-boot-device.md @@ -1,6 +1,6 @@ --- title: Advanced advice for Stop error 7B, Inaccessible_Boot_Device -description: Learn how to troubleshoot Stop error 7B or Inaccessible_Boot_Device. This error may occur after some changes are made to the computer, +description: Learn how to troubleshoot Stop error 7B or Inaccessible_Boot_Device. This error might occur after some changes are made to the computer, ms.prod: w10 ms.mktglfcycl: ms.sitesec: library @@ -15,27 +15,27 @@ manager: dansimp # Advanced troubleshooting for Stop error 7B or Inaccessible_Boot_Device -This article provides steps to troubleshoot **Stop error 7B: Inaccessible_Boot_Device**. This error may occur after some changes are made to the computer, or immediately after you deploy Windows on the computer. +This article provides steps to troubleshoot **Stop error 7B: Inaccessible_Boot_Device**. This error might occur after some changes are made to the computer, or immediately after you deploy Windows on the computer. ## Causes of the Inaccessible_Boot_Device Stop error -Any one of the following factors may cause the stop error: +Any one of the following factors might cause the stop error: -* Missing, corrupted, or misbehaving filter drivers that are related to the storage stack +* Missing, corrupted, or misbehaving filter drivers that are related to the storage stack -* File system corruption +* File system corruption -* Changes to the storage controller mode or settings in the BIOS +* Changes to the storage controller mode or settings in the BIOS -* Using a different storage controller than the one that was used when Windows was installed +* Using a different storage controller than the one that was used when Windows was installed -* Moving the hard disk to a different computer that has a different controller +* Moving the hard disk to a different computer that has a different controller -* A faulty motherboard or storage controller, or faulty hardware +* A faulty motherboard or storage controller, or faulty hardware -* In unusual cases: the failure of the TrustedInstaller service to commit newly installed updates because of Component Based Store corruptions +* In unusual cases, the failure of the TrustedInstaller service to commit newly installed updates is because of component-based store corruptions -* Corrupted files in the **Boot** partition (for example, corruption in the volume that is labeled **SYSTEM** when you run the `diskpart` > `list vol` command) +* Corrupted files in the **Boot** partition (for example, corruption in the volume that's labeled **SYSTEM** when you run the `diskpart` > `list vol` command) ## Troubleshoot this error @@ -43,9 +43,9 @@ Start the computer in [Windows Recovery Mode (WinRE)](https://docs.microsoft.com 1. Start the system by using [the installation media for the installed version of Windows](https://support.microsoft.com/help/15088). -2. On the **Install Windows** screen, select **Next** > **Repair your computer** . +2. On the **Install Windows** screen, select **Next** > **Repair your computer**. -3. On the **System Recovery Options** screen, select **Next** > **Command Prompt** . +3. On the **System Recovery Options** screen, select **Next** > **Command Prompt**. ### Verify that the boot disk is connected and accessible @@ -55,7 +55,7 @@ Start the computer in [Windows Recovery Mode (WinRE)](https://docs.microsoft.com A list of the physical disks that are attached to the computer should be displayed and resemble the following display: -``` +```console Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- --- @@ -65,7 +65,7 @@ A list of the physical disks that are attached to the computer should be display If the computer uses a Unified Extensible Firmware Interface (UEFI) startup interface, there will be an asterisk () in the **GPT* column. -If the computer uses a basic input/output system (BIOS) interface, there will not be an asterisk in the **Dyn** column. +If the computer uses a basic input/output system (BIOS) interface, there won't be an asterisk in the **Dyn** column. #### Step 2 @@ -73,7 +73,7 @@ If the `list disk` command lists the OS disks correctly, run the `list vol` comm `list vol` generates an output that resembles the following display: -``` +```console Volume ### Ltr Label Fs Type Size Status Info ---------- --- ----------- ----- ---------- ------- --------- -------- @@ -86,7 +86,7 @@ If the `list disk` command lists the OS disks correctly, run the `list vol` comm ``` >[!NOTE] ->If the disk that contains the OS is not listed in the output, you will have to engage the OEM or virtualization manufacturer. +>If the disk that contains the OS isn't listed in the output, you'll have to engage the OEM or virtualization manufacturer. ### Verify the integrity of Boot Configuration Database @@ -94,57 +94,57 @@ Check whether the Boot Configuration Database (BCD) has all the correct entries. To verify the BCD entries: -1. Examine the **Windows Boot Manager** section that has the **{bootmgr}** identifier. Make sure that the **device** and **path** entries point to the correct device and boot loader file. +1. Examine the **Windows Boot Manager** section that has the **{bootmgr}** identifier. Make sure that the **device** and **path** entries point to the correct device and boot loader file. - An example output if the computer is UEFI-based: + If the computer is UEFI-based, here's example output: - ``` + ```cmd device partition=\Device\HarddiskVolume2 path \EFI\Microsoft\Boot\bootmgfw.efi ``` - An example output if the machine is BIOS based: - ``` + If the machine is BIOS-based, here's example output: + ```cmd Device partition=C: ``` >[!NOTE] - >This output may not contain a path. + >This output might not contain a path. -2. In the **Windows Boot Loader** that has the **{default}** identifier, make sure that **device**, **path**, **osdevice**, and **systemroot** point to the correct device or partition, winload file, OS partition or device, and OS folder. +2. In the **Windows Boot Loader** that has the **{default}** identifier, make sure that **device**, **path**, **osdevice**, and **systemroot** point to the correct device or partition, winload file, OS partition or device, and OS folder. > [!NOTE] - > If the computer is UEFI-based, the filepath value specified in the **path** parameter of **{bootmgr}** and **{default}** will contain an **.efi** extension. + > If the computer is UEFI-based, the file path value that's specified in the **path** parameter of **{bootmgr}** and **{default}** contains an **.efi** extension. ![bcdedit](images/screenshot1.png) -If any of the information is wrong or missing, we recommend that you create a backup of the BCD store. To do this, run `bcdedit /export C:\temp\bcdbackup`. This command creates a backup in **C:\\temp\\** that is named **bcdbackup** . To restore the backup, run `bcdedit /import C:\temp\bcdbackup`. This command overwrites all BCD settings by using the settings in **bcdbackup** . +If any of the information is wrong or missing, we recommend that you create a backup of the BCD store. To do this, run `bcdedit /export C:\temp\bcdbackup`. This command creates a backup in **C:\\temp\\** that's named **bcdbackup**. To restore the backup, run `bcdedit /import C:\temp\bcdbackup`. This command overwrites all BCD settings by using the settings in **bcdbackup**. -After the backup is completed, run the following command to make the changes: +After the backup completes, run the following command to make the changes: 
bcdedit /set *{identifier}* option value
-For example, if the device under {default} is wrong or missing, run the following command to set it: `bcdedit /set {default} device partition=C:` +For example, if the device under {default} is wrong or missing, run this command to set it: `bcdedit /set {default} device partition=C:` - If you want to re-create the BCD completely, or if you get a message that states that "**The boot configuration data store could not be opened. The system could not find the file specified,** " run `bootrec /rebuildbcd`. + If you want to completely re-create the BCD, or if you get a message that states that "**The boot configuration data store could not be opened. The system could not find the file specified,** " run `bootrec /rebuildbcd`. -If the BCD has the correct entries, check whether the **winload** and **bootmgr** entries exist in the correct location per the path that is specified in the **bcdedit** command. By default, **bootmgr** in the BIOS partition will be in the root of the **SYSTEM** partition. To see the file, run `Attrib -s -h -r`. +If the BCD has the correct entries, check whether the **winload** and **bootmgr** entries exist in the correct location, which is in the specified path in the **bcdedit** command. By default, **bootmgr** in the BIOS partition is in the root of the **SYSTEM** partition. To see the file, run `Attrib -s -h -r`. If the files are missing, and you want to rebuild the boot files, follow these steps: -1. Copy all the contents under the **SYSTEM** partition to another location. Alternatively, you can use the command prompt to navigate to the OS drive, create a new folder, and then copy all the files and folders from the **SYSTEM** volume, as follows: +1. Copy all the contents under the **SYSTEM** partition to another location. Alternatively, you can use the command prompt to navigate to the OS drive, create a new folder, and then copy all the files and folders from the **SYSTEM** volume, like shown here: -``` -D:\> Mkdir BootBackup -R:\> Copy *.* D:\BootBackup -``` + ```cmd + D:\> Mkdir BootBackup + R:\> Copy *.* D:\BootBackup + ``` -2. If you are using Windows 10, or if you are troubleshooting by using a Windows 10 ISO at the Windows Pre-Installation Environment command prompt, you can use the **bcdboot** command to re-create the boot files, as follows: +2. If you're using Windows 10, or if you're troubleshooting by using a Windows 10 ISO at the Windows Pre-Installation Environment command prompt, you can use the **bcdboot** command to re-create the boot files, like shown here: ```cmd Bcdboot <**OSDrive* >:\windows /s <**SYSTEMdrive* >: /f ALL ``` - For example: if we assign the `` (WinRE drive) the letter R and the `` is the letter D, this command would be the following: + For example, if we assign the `` (WinRE drive) the letter R and the `` is the letter D, the following is the command that we would use: ```cmd Bcdboot D:\windows /s R: /f ALL @@ -153,13 +153,13 @@ R:\> Copy *.* D:\BootBackup >[!NOTE] >The **ALL** part of the **bcdboot** command writes all the boot files (both UEFI and BIOS) to their respective locations. -If you do not have a Windows 10 ISO, you must format the partition and copy **bootmgr** from another working computer that has a similar Windows build. To do this, follow these steps: +If you don't have a Windows 10 ISO, format the partition and copy **bootmgr** from another working computer that has a similar Windows build. To do this, follow these steps: -1. Start **Notepad** . +1. Start **Notepad**. 2. Press Ctrl+O. -3. Navigate to the system partition (in this example, it is R). +3. Navigate to the system partition (in this example, it's R). 4. Right-click the partition, and then format it. @@ -171,7 +171,7 @@ Run the following command to verify the Windows update installation and dates: Dism /Image:: /Get-packages ``` -After you run this command, you will see the **Install pending** and **Uninstall Pending** packages: +After you run this command, you'll see the **Install pending** and **Uninstall Pending** packages: ![Dism output](images/pendingupdate.png) @@ -179,27 +179,27 @@ After you run this command, you will see the **Install pending** and **Uninstall ![Dism output](images/revertpending.png) -2. Navigate to ***OSdriveLetter* :\Windows\WinSxS** , and then check whether the **pending.xml** file exists. If it does, rename it to **pending.xml.old**. +2. Navigate to ***OSdriveLetter*:\Windows\WinSxS**, and then check whether the **pending.xml** file exists. If it does, rename it to **pending.xml.old**. -3. To revert the registry changes, type **regedit** at the command prompt to open **Registry Editor**. +3. To revert the registry changes, type **regedit** at the command prompt to open **Registry Editor**. 4. Select **HKEY_LOCAL_MACHINE**, and then go to **File** > **Load Hive**. -5. Navigate to **OSdriveLetter:\Windows\System32\config**, select the file that is named **COMPONENT** (with no extension), and then select **Open**. When you are prompted, enter the name **OfflineComponentHive** for the new hive +5. Navigate to ***OSdriveLetter*:\Windows\System32\config**, select the file that's named **COMPONENT** (with no extension), and then select **Open**. When you're prompted, enter the name **OfflineComponentHive** for the new hive. ![Load Hive](images/loadhive.png) 6. Expand **HKEY_LOCAL_MACHINE\OfflineComponentHive**, and check whether the **PendingXmlIdentifier** key exists. Create a backup of the **OfflineComponentHive** key, and then delete the **PendingXmlIdentifier** key. -7. Unload the hive. To do this, highlight **OfflineComponentHive**, and then select **File** > **Unload hive**. +7. Unload the hive. To do this, highlight **OfflineComponentHive**, and then select **File** > **Unload hive**. ![Unload Hive](images/unloadhive.png)![Unload Hive](images/unloadhive1.png) -8. Select **HKEY_LOCAL_MACHINE**, go to **File** > **Load Hive**, navigate to ***OSdriveLetter* :\Windows\System32\config**, select the file that is named **SYSTEM** (with no extension), and then select **Open** . When you are prompted, enter the name **OfflineSystemHive** for the new hive. +8. Select **HKEY_LOCAL_MACHINE**, go to **File** > **Load Hive**, navigate to ***OSdriveLetter*:\Windows\System32\config**, select the file that's named **SYSTEM** (with no extension), and then select **Open**. When you're prompted, enter the name **OfflineSystemHive** for the new hive. 9. Expand **HKEY_LOCAL_MACHINE\OfflineSystemHive**, and then select the **Select** key. Check the data for the **Default** value. -10. If the data in **HKEY_LOCAL_MACHINE\OfflineSystemHive\Select\Default** is **1** , expand **HKEY_LOCAL_MACHINE\OfflineHive\ControlSet001**. If it is **2**, expand **HKEY_LOCAL_MACHINE\OfflineHive\ControlSet002**, and so on. +10. If the data in **HKEY_LOCAL_MACHINE\OfflineSystemHive\Select\Default** is **1**, expand **HKEY_LOCAL_MACHINE\OfflineHive\ControlSet001**. If it's **2**, expand **HKEY_LOCAL_MACHINE\OfflineHive\ControlSet002**, and so on. 11. Expand **Control\Session Manager**. Check whether the **PendingFileRenameOperations** key exists. If it does, back up the **SessionManager** key, and then delete the **PendingFileRenameOperations** key. @@ -207,7 +207,7 @@ After you run this command, you will see the **Install pending** and **Uninstall #### Check services -1. Follow steps 1-10 in the "Troubleshooting if this issue occurs after an Windows Update installation" section. (Step 11 does not apply to this procedure.) +1. Follow steps 1-10 in the "Troubleshooting if this issue occurs after a Windows Update installation" section. (Step 11 doesn't apply to this procedure.) 2. Expand **Services**. @@ -225,9 +225,9 @@ After you run this command, you will see the **Install pending** and **Uninstall * VOLUME -If these keys exist, check each one to make sure that it has a value that is named **Start** and that it is set to **0**. If not, set the value to **0**. +If these keys exist, check each one to make sure that it has a value that's named **Start**, and that it's set to **0**. If it's not, set the value to **0**. -If any of these keys do not exist, you can try to replace the current registry hive by using the hive from **RegBack**. To do this, run the following commands: +If any of these keys don't exist, you can try to replace the current registry hive by using the hive from **RegBack**. To do this, run the following commands: ```cmd cd OSdrive:\Windows\System32\config @@ -237,7 +237,7 @@ copy OSdrive:\Windows\System32\config\RegBack\SYSTEM OSdrive:\Windows\System32\c #### Check upper and lower filter drivers -Check whether there are any non-Microsoft upper and lower filter drivers on the computer and that they do not exist on another, similar working computer. if they do exist, remove the upper and lower filter drivers: +Check whether there are any non-Microsoft upper and lower filter drivers on the computer and that they don't exist on another, similar working computer. If they do exist, remove the upper and lower filter drivers: 1. Expand **HKEY_LOCAL_MACHINE\OfflineHive\ControlSet001\Control**. @@ -245,8 +245,8 @@ Check whether there are any non-Microsoft upper and lower filter drivers on the >[!NOTE] >These filters are mainly related to storage. After you expand the **Control** key in the registry, you can search for **UpperFilters** and **LowerFilters**. - - The following are some of the different registry entries in which you may find these filter drivers. These entries are located under **ControlSet** and are designated as **Default** : + + You might find these filter drivers in some of the following registry entries. These entries are under **ControlSet** and are designated as **Default**: \Control\Class\\{4D36E96A-E325-11CE-BFC1-08002BE10318} @@ -258,19 +258,19 @@ Check whether there are any non-Microsoft upper and lower filter drivers on the ![Registry](images/controlset.png) -If an **UpperFilters** or **LowerFilters** entry is non-standard (for example, it is not a Windows default filter driver, such as PartMgr), remove the entry by double-clicking it in the right pane, and then deleting only that value. +If an **UpperFilters** or **LowerFilters** entry is non-standard (for example, it's not a Windows default filter driver, such as PartMgr), remove the entry. To remove it, double-click it in the right pane, and then delete only that value. >[!NOTE] >There could be multiple entries. -The reason that these entries may affect us is because there may be an entry in the **Services** branch that has a START type set to 0 or 1 (indicating that it is loaded at the Boot or Automatic part of the boot process). Also, either the file that is referred to is missing or corrupted, or it may be named differently than what is listed in the entry. +These entries might affect us because there might be an entry in the **Services** branch that has a START type set to 0 or 1, which means that it's loaded at the Boot or Automatic part of the boot process. Also, either the file that's referred to is missing or corrupted, or it might be named differently than what's listed in the entry. >[!NOTE] ->If there actually is a service that is set to **0** or **1** that corresponds to an **UpperFilters** or **LowerFilters** entry, setting the service to disabled in the **Services** registry (as discussed in steps 2 and 3 of the Check services section) without removing the **Filter Driver** entry causes the computer to crash and generate a 0x7b Stop error. +>If there's a service that's set to **0** or **1** that corresponds to an **UpperFilters** or **LowerFilters** entry, setting the service to disabled in the **Services** registry (as discussed in steps 2 and 3 of the Check services section) without removing the **Filter Driver** entry causes the computer to crash and generate a 0x7b Stop error. ### Running SFC and Chkdsk - If the computer still does not start, you can try to run a **chkdisk** process on the system drive, and also run System File Checker. To do this, run the following commands at a WinRE command prompt: + If the computer still doesn't start, you can try to run a **chkdisk** process on the system drive, and then also run System File Checker. To do this, run the following commands at a WinRE command prompt: * `chkdsk /f /r OsDrive:` diff --git a/windows/client-management/troubleshoot-tcpip-connectivity.md b/windows/client-management/troubleshoot-tcpip-connectivity.md index 0d4f00510a..77e524634d 100644 --- a/windows/client-management/troubleshoot-tcpip-connectivity.md +++ b/windows/client-management/troubleshoot-tcpip-connectivity.md @@ -14,27 +14,33 @@ manager: dansimp # Troubleshoot TCP/IP connectivity -You might come across connectivity errors on the application end or timeout errors. Most common scenarios would include application connectivity to a database server, SQL timeout errors, BizTalk application timeout errors, Remote Desktop Protocol (RDP) failures, file share access failures, or general connectivity. +You might come across connectivity errors on the application end or timeout errors. The following are the most common scenarios: +- Application connectivity to a database server +- SQL timeout errors +- BizTalk application timeout errors +- Remote Desktop Protocol (RDP) failures +- File share access failures +- General connectivity -When you suspect that the issue is on the network, you collect a network trace. The network trace would then be filtered. During troubleshooting connectivity errors, you might come across TCP reset in a network capture which could indicate a network issue. +When you suspect that the issue is on the network, you collect a network trace. The network trace would then be filtered. During troubleshooting connectivity errors, you might come across TCP reset in a network capture that could indicate a network issue. -* TCP is defined as connection-oriented and reliable protocol. One of the ways in which TCP ensures this is through the handshake process. Establishing a TCP session would begin with a 3-way handshake, followed by data transfer, and then a 4-way closure. The 4-way closure where both sender and receiver agree on closing the session is termed as *graceful closure*. After the 4-way closure, the server will allow 4 minutes of time (default), during which any pending packets on the network are to be processed, this is the TIME_WAIT state. Once the TIME_WAIT state is done, all the resources allocated for this connection are released. +* TCP is defined as connection-oriented and reliable protocol. One of the ways in which TCP ensures reliability is through the handshake process. Establishing a TCP session would begin with a three-way handshake, followed by data transfer, and then a four-way closure. The four-way closure where both sender and receiver agree on closing the session is termed as *graceful closure*. After the 4-way closure, the server will allow 4 minutes of time (default), during which any pending packets on the network are to be processed, this is the TIME_WAIT state. After the TIME_WAIT state completes, all the resources allocated for this connection are released. -* TCP reset is an abrupt closure of the session which causes the resources allocated to the connection to be immediately released and all other information about the connection is erased. +* TCP reset is an abrupt closure of the session; it causes the resources allocated to the connection to be immediately released and all other information about the connection is erased. * TCP reset is identified by the RESET flag in the TCP header set to `1`. -A network trace on the source and the destination which will help you determine the flow of the traffic and see at what point the failure is observed. +A network trace on the source and the destination helps you to determine the flow of the traffic and see at what point the failure is observed. The following sections describe some of the scenarios when you will see a RESET. ## Packet drops -When one TCP peer is sending out TCP packets for which there is no response received from the other end, the TCP peer would end up re-transmitting the data and when there is no response received, it would end the session by sending an ACK RESET( meaning, application acknowledges whatever data exchanged so far, but due to packet drop closing the connection). +When one TCP peer is sending out TCP packets for which there is no response received from the other end, the TCP peer would end up retransmitting the data and when there is no response received, it would end the session by sending an ACK RESET (this means that the application acknowledges whatever data is exchanged so far, but because of packet drop, the connection is closed). The simultaneous network traces on source and destination will help you verify this behavior where on the source side you would see the packets being retransmitted and on the destination none of these packets are seen. This would mean, the network device between the source and destination is dropping the packets. -If the initial TCP handshake is failing because of packet drops then you would see that the TCP SYN packet is retransmitted only 3 times. +If the initial TCP handshake is failing because of packet drops, then you would see that the TCP SYN packet is retransmitted only three times. Source side connecting on port 445: @@ -44,7 +50,7 @@ Destination side: applying the same filter, you do not see any packets. ![Screenshot of frame summary with filter in Network Monitor](images/tcp-ts-7.png) -For the rest of the data, TCP will retransmit the packets 5 times. +For the rest of the data, TCP will retransmit the packets five times. **Source 192.168.1.62 side trace:** @@ -58,16 +64,16 @@ If you are seeing that the SYN packets are reaching the destination, but the des ## Incorrect parameter in the TCP header -You see this behavior when the packets are modified in the network by middle devices and TCP on the receiving end is unable to accept the packet, such as the sequence number being modified, or packets being re-played by middle device by changing the sequence number. Again, the simultaneous network trace on the source and destination will be able to tell you if any of the TCP headers are modified. Start by comparing the source trace and destination trace, you will be able to notice if there is a change in the packets itself or if any new packets are reaching the destination on behalf of the source. +You see this behavior when the packets are modified in the network by middle devices and TCP on the receiving end is unable to accept the packet, such as the sequence number being modified, or packets being replayed by middle device by changing the sequence number. Again, the simultaneous network trace on the source and destination will be able to tell you if any of the TCP headers are modified. Start by comparing the source trace and destination trace, you will be able to notice if there is a change in the packets itself or if any new packets are reaching the destination on behalf of the source. -In this case, you will again need help from the network team to identify any such device which is modifying packets or re-playing packets to the destination. The most common ones are RiverBed devices or WAN accelerators. +In this case, you'll again need help from the network team to identify any device that's modifying packets or replaying packets to the destination. The most common ones are RiverBed devices or WAN accelerators. ## Application side reset When you have identified that the resets are not due to retransmits or incorrect parameter or packets being modified with the help of network trace, then you have narrowed it down to application level reset. -The application resets are the ones where you see the Acknowledgement flag set to `1` along with the reset flag. This would mean that the server is acknowledging the receipt of the packet but for some reason it will not accept the connection. This is when the application that received the packet did not like something it received. +The application resets are the ones where you see the Acknowledgment flag set to `1` along with the reset flag. This would mean that the server is acknowledging the receipt of the packet but for some reason it will not accept the connection. This is when the application that received the packet did not like something it received. In the below screenshots, you see that the packets seen on the source and the destination are the same without any modification or any drops, but you see an explicit reset sent by the destination to the source. @@ -83,7 +89,7 @@ You also see an ACK+RST flag packet in a case when the TCP establishment packet ![Screenshot of packet flag](images/tcp-ts-11.png) -The application which is causing the reset (identified by port numbers) should be investigated to understand what is causing it to reset the connection. +The application that's causing the reset (identified by port numbers) should be investigated to understand what is causing it to reset the connection. >[!Note] >The above information is about resets from a TCP standpoint and not UDP. UDP is a connectionless protocol and the packets are sent unreliably. You would not see retransmission or resets when using UDP as a transport protocol. However, UDP makes use of ICMP as a error reporting protocol. When you have the UDP packet sent out on a port and the destination does not have port listed, you will see the destination sending out **ICMP Destination host unreachable: Port unreachable** message immediately after the UDP packet @@ -96,7 +102,7 @@ The application which is causing the reset (identified by port numbers) should b ``` -During the course of troubleshooting connectivity issue, you might also see in the network trace that a machine receives packets but does not respond to. In such cases, there could be a drop at the server level. You should enable firewall auditing on the machine to understand if the local firewall is dropping the packet. +During the course of troubleshooting connectivity issue, you might also see in the network trace that a machine receives packets but does not respond to. In such cases, there could be a drop at the server level. To understand whether the local firewall is dropping the packet, enable the firewall auditing on the machine. ``` auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable @@ -106,6 +112,6 @@ You can then review the Security event logs to see for a packet drop on a partic ![Screenshot of Event Properties](images/tcp-ts-12.png) -Now, run the command `netsh wfp show state`, this will generate a wfpstate.xml file. Once you open this file and filter for the ID you find in the above event (2944008), you will be able to see a firewall rule name associated with this ID which is blocking the connection. +Now, run the command `netsh wfp show state`, this will generate a wfpstate.xml file. After you open this file and filter for the ID that you find in the above event (2944008), you'll be able to see a firewall rule name that's associated with this ID that's blocking the connection. ![Screenshot of wfpstate.xml file](images/tcp-ts-13.png) diff --git a/windows/security/threat-protection/auditing/audit-detailed-file-share.md b/windows/security/threat-protection/auditing/audit-detailed-file-share.md index 69a9d636c7..3b223b9331 100644 --- a/windows/security/threat-protection/auditing/audit-detailed-file-share.md +++ b/windows/security/threat-protection/auditing/audit-detailed-file-share.md @@ -37,9 +37,9 @@ There are no system access control lists (SACLs) for shared folders. If this pol | Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | |-------------------|-----------------|-----------------|------------------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Domain Controller | No | Yes | No | Yes | Audit Success for this subcategory on domain controllers typically will lead to very high volume of events, especially for SYSVOL share.
We recommend monitoring Failure access attempts: the volume should not be very high. You will be able to see who was not able to get access to a file or folder on a network share on a computer. | -| Member Server | IF | Yes | IF | Yes | IF – If a server has shared network folders which typically get many access requests (File Server, for example), the volume of events might be very high. If you really need to track all successful access events for every file or folder located on a shared folder, enable Success auditing or use the [Audit File System](audit-file-system.md) subcategory, although that subcategory excludes some information in Audit Detailed File Share, for example, the client’s IP address.
The volume of Failure events for member servers should not be very high (if they are not File Servers). With Failure auditing, you will be able to see who was not able to get access to a file or folder on a network share on this computer. | -| Workstation | IF | Yes | IF | Yes | IF – If a workstation has shared network folders which typically get many access requests, the volume of events might be very high. If you really need to track all successful access events for every file or folder located on a shared folder, enable Success auditing or use Audit File System subcategory, although that subcategory excludes some information in Audit Detailed File Share, for example, the client’s IP address.
The volume of Failure events for workstations should not be very high. With Failure auditing, you will be able to see who was not able to get access to a file or folder on a network share on this computer. | +| Domain Controller | No | Yes | No | Yes | Audit Success for this subcategory on domain controllers typically will lead to high volume of events, especially for SYSVOL share.
We recommend monitoring Failure access attempts: the volume should not be high. You will be able to see who was not able to get access to a file or folder on a network share on a computer. | +| Member Server | IF | Yes | IF | Yes | IF – If a server has shared network folders that typically get many access requests (File Server, for example), the volume of events might be high. If you really need to track all successful access events for every file or folder located on a shared folder, enable Success auditing or use the [Audit File System](audit-file-system.md) subcategory, although that subcategory excludes some information in Audit Detailed File Share, for example, the client’s IP address.
The volume of Failure events for member servers should not be high (if they are not File Servers). With Failure auditing, you can see who can't access a file or folder on a network share on this computer. | +| Workstation | IF | Yes | IF | Yes | IF – If a workstation has shared network folders that typically get many access requests, the volume of events might be high. If you really need to track all successful access events for every file or folder located on a shared folder, enable Success auditing or use Audit File System subcategory, although that subcategory excludes some information in Audit Detailed File Share, for example, the client’s IP address.
The volume of Failure events for workstations should not be high. With Failure auditing, you can see who can't access a file or folder on a network share on this computer. | **Events List:** diff --git a/windows/security/threat-protection/auditing/audit-group-membership.md b/windows/security/threat-protection/auditing/audit-group-membership.md index e9047b6c8a..5775f97220 100644 --- a/windows/security/threat-protection/auditing/audit-group-membership.md +++ b/windows/security/threat-protection/auditing/audit-group-membership.md @@ -1,6 +1,6 @@ --- title: Audit Group Membership (Windows 10) -description: The advanced security audit policy setting, Audit Group Membership, enables you to audit group memberships when they are enumerated on the client PC. +description: Using the advanced security audit policy setting, Audit Group Membership, you can audit group memberships when they're enumerated on the client PC. ms.assetid: 1CD7B014-FBD9-44B9-9274-CC5715DE58B9 ms.reviewer: manager: dansimp @@ -20,8 +20,7 @@ ms.date: 04/19/2017 - Windows 10 - Windows Server 2016 - -Audit Group Membership enables you to audit group memberships when they are enumerated on the client computer. +By using Audit Group Membership, you can audit group memberships when they're enumerated on the client computer. This policy allows you to audit the group membership information in the user's logon token. Events in this subcategory are generated on the computer on which a logon session is created. @@ -33,15 +32,15 @@ Multiple events are generated if the group membership information cannot fit in **Event volume**: -- Low on a client computer. +- Low on a client computer. -- Medium on a domain controller or network servers. +- Medium on a domain controller or network servers. | Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | |-------------------|-----------------|-----------------|------------------|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Domain Controller | Yes | No | Yes | No | Group membership information for logged in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | -| Member Server | Yes | No | Yes | No | Group membership information for logged in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | -| Workstation | Yes | No | Yes | No | Group membership information for logged in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | +| Domain Controller | Yes | No | Yes | No | Group membership information for a logged-in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group, or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so this subcategory doesn't have a recommendation to enable Failure auditing. | +| Member Server | Yes | No | Yes | No | Group membership information for logged in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group, or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so this subcategory doesn't have a recommendation to enable Failure auditing. | +| Workstation | Yes | No | Yes | No | Group membership information for a logged-in user can help to detect that member of specific domain or local group logged in to the machine (for example, member of database administrators, built-in local administrators, domain administrators, service accounts group, or other high value groups).
For recommendations for using and analyzing the collected information, see the ***Security Monitoring Recommendations*** sections.
This subcategory doesn’t have Failure events, so this subcategory doesn't have a recommendation to enable Failure auditing. | **Events List:** diff --git a/windows/security/threat-protection/auditing/audit-logoff.md b/windows/security/threat-protection/auditing/audit-logoff.md index c4d6606795..011a5d397c 100644 --- a/windows/security/threat-protection/auditing/audit-logoff.md +++ b/windows/security/threat-protection/auditing/audit-logoff.md @@ -23,7 +23,7 @@ ms.date: 07/16/2018 Audit Logoff determines whether the operating system generates audit events when logon sessions are terminated. -These events occur on the computer that was accessed. In the case of an interactive logon, these events are generated on the computer that was logged on to. +These events occur on the computer that was accessed. For an interactive logon, these events are generated on the computer that was logged on to. There is no failure event in this subcategory because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record. @@ -31,13 +31,13 @@ Logon events are essential to understanding user activity and detecting potentia **Event volume**: High. -This subcategory allows you to audit events generated by the closing of a logon session. These events occur on the computer that was accessed. For an interactive logoff the security audit event is generated on the computer that the user account logged on to. +This subcategory allows you to audit events generated by the closing of a logon session. These events occur on the computer that was accessed. For an interactive logoff, the security audit event is generated on the computer that the user account logged on to. | Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | |-------------------|-----------------|-----------------|------------------|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Domain Controller | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It is more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long session was active (in correlation with [Audit Logon](audit-logon.md) events) and when user actually logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | -| Member Server | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It is more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long session was active (in correlation with [Audit Logon](audit-logon.md) events) and when user actually logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | -| Workstation | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It is more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long session was active (in correlation with [Audit Logon](audit-logon.md) events) and when user actually logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | +| Domain Controller | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It's more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long a session was active (in correlation with [Audit Logon](audit-logon.md) events) and when a user logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | +| Member Server | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It's more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long a session was active (in correlation with [Audit Logon](audit-logon.md) events) and when a user logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | +| Workstation | No | No | Yes | No | This subcategory typically generates huge amount of “[4634](event-4634.md)(S): An account was logged off.” events, which typically have little security relevance. It's more important to audit Logon events using [Audit Logon](audit-logon.md) subcategory, rather than Logoff events.
Enable Success audit if you want to track, for example, for how long a session was active (in correlation with [Audit Logon](audit-logon.md) events) and when a user logged off.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | **Events List:** diff --git a/windows/security/threat-protection/auditing/audit-non-sensitive-privilege-use.md b/windows/security/threat-protection/auditing/audit-non-sensitive-privilege-use.md index f1227802bd..b75e993891 100644 --- a/windows/security/threat-protection/auditing/audit-non-sensitive-privilege-use.md +++ b/windows/security/threat-protection/auditing/audit-non-sensitive-privilege-use.md @@ -1,6 +1,6 @@ --- -title: Audit Non Sensitive Privilege Use (Windows 10) -description: This topic for the IT professional describes the Advanced Security Audit policy setting, Audit Non-Sensitive Privilege Use, which determines whether the operating system generates audit events when non-sensitive privileges (user rights) are used. +title: Audit Non-Sensitive Privilege Use (Windows 10) +description: This article for the IT professional describes the Advanced Security Audit policy setting, Audit Non-Sensitive Privilege Use, which determines whether the operating system generates audit events when non-sensitive privileges (user rights) are used. ms.assetid: 8fd74783-1059-443e-aa86-566d78606627 ms.reviewer: manager: dansimp @@ -14,14 +14,14 @@ author: dansimp ms.date: 04/19/2017 --- -# Audit Non Sensitive Privilege Use +# Audit Non-Sensitive Privilege Use **Applies to** - Windows 10 - Windows Server 2016 -Audit Non Sensitive Privilege Use contains events that show usage of non-sensitive privileges. This is the list of non-sensitive privileges: +Audit Non-Sensitive Privilege Use contains events that show usage of non-sensitive privileges. This is the list of non-sensitive privileges: - Access Credential Manager as a trusted caller