All posts tagged error

DirectAccess Fails on Windows 11 24H2

Microsoft recently released Windows 11 24H2. Not long after the release there have been numerous reports of DirectAccess failing after performing an in-place upgrade from previous versions of Windows 11. New installations of Windows 11 24H2 experience the same problem.

Update 10/28/2024: This issue is resolved with KB5044384.

Testing

After downloading and configuring a Windows 11 24H2 test client I was able to quickly reproduce the issue. While previous versions of Windows 11 can connect to my test DirectAccess server without issue, the Windows 11 24H2 client fails.

Troubleshooting

Looking at the DirectAccess status indicator in the UI the DirectAccess connection remains ‘Connecting’ perpetually. Further investigation indicates an IP-HTTPS interface error. Running the command netsh.exe interface httpstunnel show interface reveals an error code 0x57 (invalid parameter) with the following error message.

Failed to connect to the IPHTTPS server. Waiting to reconnect.

Workaround

Currently there is no known root cause for this issue and there is no available workaround. Administrators should delay upgrading to Windows 11 24H2 if DirectAccess is deployed in the organization. I will continue to investigate and post additional information as I learn more. Stay tuned!

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

Microsoft DirectAccess Now Formally Deprecated

7 Comments
by Richard M. Hicks on October 7, 2024  •  Permalink
Posted in DirectAccess, Enterprise, enterprise mobility, Infrastructure, IP-HTTPS, Microsoft, Mobility, network connectivity status indicator, Reddit, Remote Access, TLS, transition technology, troubleshooting, Windows 11
Tagged , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on October 7, 2024

https://directaccess.richardhicks.com/2024/10/07/directaccess-fails-on-windows-11-24h2/

Troubleshooting Intune Failed PKCS Request

Always On VPN administrators deploying on-premises enterprise PKI certificates using Microsoft Intune with PKCS may encounter a scenario where a certificate fails to be issued to a user or device. In this post, I’ll share some things to investigate when troubleshooting this issue.

Event 1001

To begin, open the Event Log and navigate to Applications and Services > Microsoft > Intune > CertificateConnectors > Admin. You will likely find an event ID 1001 from the CertificateConnectors source with the following error message.

Failed to process PKCS request.

Prerequisites

Validate the following prerequisites have been met on the issuing Certification Authority (CA) server.

Certificate Template

Ensure the certificate template used for PKCS has the correct permissions and is published on an issuing CA server. Open the Certificate Templates management console (certtmpl.msc), right-click the certificate template, choose Properties, and then click on the Security tab. The certificate template must grant the Intune Certificate connector server’s computer account (or the PKCS connector’s service account if running as a service and not SYSTEM) the Read and Enroll permissions on the template.

CA Permissions

In addition to the permissions on the certificate template, ensure the correct permissions have been configured on the issuing CA itself. Right-click on the CA in the Certification Authority management console (certsrv.msc) and choose Security. Ensure the Intune Certificate connector server’s computer account (or the PKCS connector’s service account, if running as a service and not SYSTEM) is granted The Issue and Manage Certificates and Request Certificates permissions.

Intune Policy

Ensure the Intune device configuration policy is configured correctly. These three fields are critical and can result in failed PKCS certificate deployment if misconfigured.

Certification Authority

Enter the fully qualified domain name (FQDN) of the on-premises issuing CA server in this field.

Certification Authority Name

Enter the common name of the issuing CA in this field. You will find this information by running the following command on any domain-joined Windows system.

certutil.exe -dump

Certificate Template Name

Enter the name of the certificate template in Active Directory. Be aware that the template name and template display name are two different things. The template name is usually the template display name without spaces. However, that’s not a guarantee. On the General tab of the certificate template, look at the template name field on the certificate template to confirm.

Summary

This article is not a comprehensive troubleshooting guide for problems associated with failed PKCS certificate deployment using the Microsoft Intune Certificate connector and PKCS. However, it covers some of the more common problems administrators will likely encounter. If you cannot provision PKCS certificates correctly, drop me a note and I’ll provide further guidance.

Additional Information

Troubleshooting Failed Intune Certificate Connector Configuration – Part 1

Troubleshooting Failed Intune Certificate Connector Configuration – Part 2

Intune Certificate Connector Service Account and PKCS

Microsoft Intune Cloud PKI

Microsoft Intune Cloud PKI and Certificate Templates

Microsoft Intune Cloud PKI and Active Directory

2 Comments
by Richard M. Hicks on June 24, 2024  •  Permalink
Posted in Active Directory, Active Directory Certificate Services, AD CS, ADCS, administration, Always On VPN, AOVPN, authentication, Azure, Certificate Authentication, Certificate Authority, Certificate Connector for Intune, Certificate Services, certificates, cloud, Cloud PKI, Cloud Service, Cryptography, Deployment, Device Management, Encryption, Endpoint Manager, Enterprise, enterprise mobility, extensible authentication protocol, Hybrid Azure AD Join, Infrastructure, Intune, Intune Certificate Connector, Intune PFX Connector, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Operational Support, PFX Connector, PKCS, PKI, public key infrastructure, Remote Access, Security, systems management, troubleshooting, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 24, 2024

https://directaccess.richardhicks.com/2024/06/24/troubleshooting-intune-failed-pkcs-request/

Always On VPN Device Tunnel Issues with April 2024 Security Update

Always On VPN administrators may find that their device tunnel connections no longer connect automatically after applying the April 2024 security updates. The device tunnel connection is optional and only required under specific conditions, so end users may not be immediately impacted. However, administrators should be aware of this issue.

Note: The issues outlined in this post have been resolved with the May 14, 2024, security updates.

Error Messages

When manually establishing an Always On VPN device tunnel connection using rapshone.exe or rasdial.exe, you may receive one of the following error messages.

Rasphone.exe

Error 0x80070057: The parameter is incorrect.

Rasdial.exe

Connecting to <Name of Device Tunnel>…The parameter is incorrect.

Affected Devices

The issue affects all supported versions of Windows with an Always On VPN device tunnel connection configured to require a specific Enhanced Key Usage (EKU) OID. Administrators can run the following PowerShell command to identify this configuration.

Get-VpnConnection -AllUserConnection -Name <Name of Device Tunnel> | Select-Object MachineCertificateEkuFilter

If the output of this PowerShell command returns data, it is affected by this issue.

Workaround

To restore Always On VPN device tunnel functionality on devices with the April 2024 security updates installed, open an elevated PowerShell command window and run the following command.

Set-VpnConnection -AllUserConnection -Name ‘Always On VPN Device Tunnel’ -MachineCertificateEKUFilter $Null

After running this command, the output should now be blank.

Caveat

The problem with implementing the workaround described here is that you likely enabled this configuration to address an issue where the wrong certificate was selected for use with the device tunnel. In this case, the workaround may result in unexpected behavior and may not restore full functionality.

Known Issue Rollback

Currently, Microsoft is aware of the issue and is actively working to resolve it. If you are experiencing this issue, open a support case with Microsoft, and they will provide you with more information and possibly a private Known Issue Rollback (KIR). I will update this post as soon as Microsoft publishes a permanent fix.

Additional Information

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Only Deployment Considerations

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

2 Comments
by Richard M. Hicks on April 23, 2024  •  Permalink
Posted in Always On VPN, AOVPN, Certificate Authentication, certificates, device tunnel, Enterprise, enterprise mobility, IKEv2, Microsoft, Mobility, Operational Support, PowerShell, Remote Access, Security, Security Update, troubleshooting, Update, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 23, 2024

https://directaccess.richardhicks.com/2024/04/23/always-on-vpn-device-tunnel-issues-with-april-2024-security-update/

« Older Posts
Newer Posts »