You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: memdocs/autopilot/known-issues.md
+18Lines changed: 18 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,24 @@ This article describes known issues that can often be resolved by configuration
28
28
29
29
## Known issues
30
30
31
+
### Device-based Conditional Access policies
32
+
33
+
1. The Intune Enrollment app must be excluded from any Conditional Access policy requiring **Terms of Use** because it isn’t supported. See [Per-device terms of use](/azure/active-directory/conditional-access/terms-of-use#per-device-terms-of-use).
34
+
35
+
2. Exceptions to Conditional Access policies to exclude **Microsoft Intune Enrollment** and **Microsoft Intune** cloud apps are needed to complete Autopilot enrollment in cases where restrictive polices are present such as:
36
+
- Conditional Access policy 1: Block all apps except those on an exclusion list.
37
+
- Conditional Access policy 2: Require a compliant device for the apps on the exclusion list.
38
+
39
+
In this case, Microsoft Intune Enrollment and Microsoft Intune should be included in that exclusion list of policy 1.
40
+
41
+
If a policy is in place such that **all cloud apps** require a compliant device (there is no exclusion list), Microsoft Intune Enrollment will already be excluded by default, so that the device can register with Azure AD and enroll with Intune and avoid a circular dependency.
42
+
43
+
3.**Hybrid Azure AD devices**: When Hybrid Azure AD devices are deployed with Autopilot, 2 device IDs are initially associated with the same device – one Azure AD and one hybrid. The hybrid compliance state will display as **N/A** when viewed from the devices list in the Azure portal until a user signs in. Intune only syncs with the Hybrid device ID after a successful user sign-in.
44
+
45
+
The temporary **N/A** compliance state can cause issues with device based Conditional Access polices that block access based on compliance. In this case, Conditional Access is behaving as intended. To resolve the conflict, a user must to sign in to the device, or the device-based policy must be modified. For more information, see [Conditional Access: Require compliant or hybrid Azure AD joined device](/azure/active-directory/conditional-access/howto-conditional-access-policy-compliant-device).
46
+
47
+
4. Conditional Access policies such as BitLocker compliance require a grace period for Autopilot devices, because until the device has been rebooted the status of BitLocker and Secure Boot have not been captured, and cannot be used as part of the Compliance Policy. The grace period can be as short as 0.25 days.
48
+
31
49
### Device goes through Autopilot deployment without an assigned profile
32
50
33
51
When a device is registered in Autopilot and no profile is assigned, it will take the default Autopilot profile. This is by design to ensure that all devices registered with Autopilot, goes through the Autopilot experience. If you do not want the device to go through an Autopilot deployment, you must remove the Autopilot registration.
Copy file name to clipboardExpand all lines: memdocs/intune/protect/certificates-digicert-configure.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -340,4 +340,4 @@ Intune Certificate Connector service logs are available in **%ProgramFiles%\Micr
340
340
341
341
## Next steps
342
342
343
-
Use the information in this article with the information in [What are Microsoft Intune device profiles?](../configuration/device-profiles.md) to manage your organization's devices and the certificates on them.
343
+
Use the information in this article with the information in [What are Microsoft Intune device profiles?](../configuration/device-profiles.md) to manage your organization's devices and the certificates on them. <!-- test -->
Copy file name to clipboardExpand all lines: memdocs/intune/protect/endpoint-security-account-protection-policy.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ Use Intune endpoint security policies for account protection to protect the iden
34
34
35
35
Find the endpoint security policies for Account protection under *Manage* in the **Endpoint security** node of the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
36
36
37
-
View [settings for account protection profiles](../protect/endpoint-security-asr-profile-settings.md).
37
+
View [settings for account protection profiles](../protect/endpoint-security-account-protection-profile-settings.md).
- Review and [Configure prerequisites for Microsoft Tunnel](microsoft-tunnel-prerequisites.md).
32
31
- Run the Microsoft Tunnel [readiness tool](../protect/microsoft-tunnel-prerequisites.md#run-the-readiness-tool) to confirm your environment is ready to support use of the tunnel.
33
32
@@ -45,7 +44,10 @@ Use of a *Server configuration* lets you create a configuration a single time an
45
44
46
45
3. On the **Settings** tab, configure the following items:
47
46
48
-
-**IP address range**: IP addresses within this range are leased to devices when they connect to Tunnel Gateway. For example, *169.254.0.0/16*.
47
+
-**IP address range**: IP addresses within this range are leased to devices when they connect to Tunnel Gateway. The Tunnel Client IP address range specified must not conflict with an on-premises network range.
48
+
- Consider using the Automatic Private IP Addressing (APIPA) range of 169.254.0.0/16, as this range avoids conflicts with other corporate networks.
49
+
- If the client IP address range conflicts with the destination, it will loopback and fail to communicate with the corporate network.
50
+
- You can select any client IP address range you want to use if it does not conflict with your corporate network IP address ranges.
49
51
50
52
-**DNS servers**: These servers are used when a DNS request comes from a device that's connected to Tunnel Gateway.
Copy file name to clipboardExpand all lines: memdocs/intune/protect/microsoft-tunnel-overview.md
+2-4Lines changed: 2 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ keywords:
5
5
author: brenduns
6
6
ms.author: brenduns
7
7
manager: dougeby
8
-
ms.date: 03/01/2022
8
+
ms.date: 03/03/2022
9
9
ms.topic: how-to
10
10
ms.service: microsoft-intune
11
11
ms.subservice: protect
@@ -131,7 +131,7 @@ The Microsoft Tunnel Gateway runs in containers that run on Linux servers.
131
131
>
132
132
> - Tunnel gateway maintains two channels with the client. A control channel is established over TCP, and TLS. This also serves as a backup data channel. It then looks to establish a UDP channel using DTLS (Datagram TLS, an implementation of TLS over UDP) that serves as the main data channel. If the UDP channel fails to establish or is temporarily unavailable, the backup channel over TCP/TLS is used. By default port 443 is used for both TCP and UDP, but this can be customized via the Intune Server Configuration - [*Server port* setting](../protect/microsoft-tunnel-configure.md#create-a-server-configuration). If changing the default port (443) ensure your inbound firewall rules are adjusted to the custom port.
133
133
>
134
-
> - The assigned client IP addresses (the*IP address range* setting in a [Server configuration](../protect/microsoft-tunnel-configure.md#to-create-a-server-configuration) for Tunnel) are not visible to other devices on the network. These addresses won't conflict with any internal/corporate network IP address on the network. Client traffic will have the source IP address of the Linux server host. Microsoft Tunnel Gateway uses port address translation (PAT). PAT is a type of network address translation (NAT) where multiple private IP addresses from the Server configuration are mapped into a single IP (many-to-one) by using ports. Client traffic will have the source IP address of the Linux server host.
134
+
> - The assigned client IP addresses (the*IP address range* setting in a [Server configuration](../protect/microsoft-tunnel-configure.md#to-create-a-server-configuration) for Tunnel) are not visible to other devices on the network. Microsoft Tunnel Gateway uses port address translation (PAT). PAT is a type of network address translation (NAT) where multiple private IP addresses from the Server configuration are mapped into a single IP (many-to-one) by using ports. Client traffic will have the source IP address of the Linux server host.
135
135
136
136
**Break and inspect**:
137
137
@@ -155,8 +155,6 @@ The following outlines where break and inspect is not supported and where it is
155
155
156
156
- The Management Agent is authorized against Azure AD using Azure app ID/secret keys.
157
157
158
-
- The Tunnel Gateway server uses NAT to provide addresses to VPN clients that are connecting to the corporate network.
159
-
160
158
## Next steps
161
159
162
160
[Prerequisites for the Microsoft Tunnel in Intune](microsoft-tunnel-prerequisites.md)
Copy file name to clipboardExpand all lines: memdocs/intune/protect/microsoft-tunnel-prerequisites.md
+68-1Lines changed: 68 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ keywords:
5
5
author: brenduns
6
6
ms.author: brenduns
7
7
manager: dougeby
8
-
ms.date: 02/17/2022
8
+
ms.date: 03/03/2022
9
9
ms.topic: how-to
10
10
ms.service: microsoft-intune
11
11
ms.subservice: protect
@@ -109,6 +109,73 @@ with documentation for the application, and packages with helper utilities. For
109
109
110
110
-**TLS version**: By default, connections between Microsoft Tunnel clients and servers use TLS 1.3. When TLS 1.3 isn’t available, the connection can fall back to use TLS 1.2.
111
111
112
+
### Default bridge network
113
+
114
+
Both Podman and Docker containers use a bridge network to forward traffic through the Linux host. When the containers bridge network conflicts with a corporate network, Tunnel Gateway can’t successfully route traffic to that corporate network.
115
+
116
+
The default bridge networks are:
117
+
118
+
- Docker: **172.17.0.0/16**
119
+
- Podman: **10.0.88.0.0/16**
120
+
121
+
To avoid conflicts, you can reconfigure both Podman and Docker to use a bridge network that you specify.
122
+
123
+
> [!IMPORTANT]
124
+
> The Tunnel Gateway server must be installed before you can change the bridge network configuration.
125
+
126
+
#### Change the default bridge network used by Docker
127
+
128
+
Docker uses the file **/etc/docker/daemon.json** to configure a new default bridge IP address. In the file, the bridge IP address must be specified in CIDR (Classless inter-domain routing) notation, a compact way to represent an IP address along with its associated subnet mask and routing prefix.
129
+
130
+
> [!IMPORTANT]
131
+
> The IP address that's used in the following steps is an example. Be sure the IP address you use doesn't conflict with your corporate network.
132
+
133
+
1. Use the following command to stop the MS Tunnel Gateway container: `sudo mst-cli server stop ; sudo mst-cli agent stop`
134
+
135
+
2. Next, run the following command to remove the existing Docker bridge device: `sudo ip link del docker0`
136
+
137
+
3. If the file **/etc/docker/daemon.json** is present on your server, use a file editor like *vi* or *nano* to modify the file. Run the file editor with root or sudo permissions:
138
+
139
+
- When the **“bip”:** entry is present with an IP address, modify it by adding a new IP address in CIDR notation.
140
+
- When the **“bip”:** entry isn't present, you must add both the value **"bip":** and the new IP address in CIDR notation.
141
+
142
+
The following example shows the structure of a *daemon.json* file with an updated **“bip”:** entry that uses a modified IP address of **“192.168.128.1/24”**.
143
+
144
+
Example of daemon.json:
145
+
146
+
```
147
+
{
148
+
"bip": "192.168.128.1/24"
149
+
}
150
+
```
151
+
152
+
4. If the file **/etc/docker/daemon.json** isn’t present on your server, run a command similar to the following example to create the file and define the bridge IP that you want to use.
5. Use the following command to start the MS Tunnel Gateway container: `sudo mst-cli agent start ; sudo mst-cli server start`
157
+
158
+
For more information, see [Use bridge networks](https://docs.docker.com/network/bridge/#configure-the-default-bridge-network) in the Docker documentation.
159
+
160
+
#### Change the default bridge network used by Podman
161
+
162
+
Podman uses the file **/etc/cni/net.d as 87-podman-bridge.conflist** to configure a new default bridge IP address.
163
+
164
+
1. Use the following command to stop the MS Tunnel Gateway container: `sudo mst-cli server stop ; sudo mst-cli agent stop`
165
+
166
+
2. Next, run the following command to remove the existing Podman bridge device: `sudo ip link del cni-podman0`
167
+
168
+
3. Using root permissions and a file editor like *vi* or *nano*, modify **/etc/cni/net.d as 87-podman-bridge.conflist** to update the defaults for **“subnet:”** and **“gateway:”** by replacing the Podman default values with your desired subnet and gateway addresses. The *subnet* address must be specified in CIDR notation.
169
+
170
+
The Podman defaults are:
171
+
172
+
- subnet: 10.88.0.0/16
173
+
- gateway: 10.88.0.1
174
+
175
+
4. Use the following command to restart the MS Tunnel Gateway containers: `sudo mst-cli agent start ; sudo mst-cli server start`
176
+
177
+
For more information, see [Configuring container networking with Podman](https://www.redhat.com/sysadmin/container-networking-podman) in the Red Hat documentation.
178
+
112
179
## Network
113
180
114
181
-**Enable packet forwarding for IPv4**: Each Linux server that hosts the Tunnel server software must have IP forwarding for IPv4 enabled. To check on the status of IP forwarding, on the server run one of the following generic commands as *root* or *sudo*. Both commands return a value of **0** for *disabled* and a value of **1** for *enabled*:
0 commit comments