[AzureAD - Conditional Access - VPN Connectivity - Certificate Expired]

Question

[AzureAD - Conditional Access - VPN Connectivity - Certificate Expired]

tn57chgs-3733 6

tn57chgs-3733 asked • 12 hours ago | tn57chgs-3733 edited • 12 hours ago
Actions
[AzureAD - Conditional Access - VPN Connectivity - Certificate Expired]

Today I faced an issue while connecting to AOVPN. Looking at the event logs [EventID: 20291 - RasClient - *** Always On VPN requires attention] from the device, I was not able to figure out the root cause of the issue, and the behavior was like when you click on connect, it opens azure ad interactive sign in page, and after the successful sign-in it keeps prompting for the same over and over again and finally errors out with a message "device not compliant" without a correlation ID, and the error seems to be inappropriate as my device was compliant and WAN Miniport (SSTP) adapter should have allowed me to connect AOVPN. Moreover, Azure AD sign-in logs do not show any failures as well.

So after hours of troubleshooting, I figured out that a short-lived certificate was missing, and the root certificate of the (VPN server) client app was expired [which was created while setting up CA policies for the clients to connect AOVPN ]. So after I started a new one under conditional access blade --> vpn connectivity, I connected my device to AOVPN and satisfied the claims set in the conditional access policy.
Now, there are two things as follows which I would like to understand

Where are these certificates stored?
Can global admins view and manage them?
According to MS, creating a new certificate from the conditional access blade makes a client app named "VPN Server." So what behavior is when you go for a second certificate after the first expires? Will it create a new VPN Server client app or replace the expired one? My guess is it will add another one as a version like Azure key vault.

Can the duration extend? Right now, it only shows 1, 2, and 3 years.

My last question here would be, according to this article, the VPN root certificate (cloud root certificates) created from CA Blade should be added to the on-prem active directory Enterprise NTauth store. Is it a mandatory step? Without even doing so, I can connect to AOVPN without any issues.

2 answers

Your answer

Answer 1

JamesTran-MSFT 36,861 Microsoft Employee

@tn57chgs-3733
Thank you for your detailed post and I apologize for the delayed response!

I understand that you have some questions regarding the Always-On-VPN, and when it comes to the Azure AD side of things, I'll do my best to answer these or point you in the right direction.

Where are these certificates stored and can Global Admins view and manage them

VPN certificate information such as certificate thumbprint and certificate expiration information, are stored as a service principal named "VPN Server" in Azure AD.
A user with least privileged role can view, but not modify service principal information.
Only the Global Administrator, Application Administrator, Cloud Application Administrator, Hybrid Identity Administrator, Directory Synchronization Accounts and Service Principal owners are permitted to update or delete service principal information including "VPN Server". For more info.

Creating a new certificate from the conditional access blade makes a client app named "VPN Server." What behavior is when you go for a second certificate after the first expires? Will it create a new VPN Server client app or replace the expired one?

The VPN Server client app that's created is a Service Principal object, so a second app won't be created when you create a second certificate after the first one expires. For more info.

Can the duration extend? Right now, it only shows 1, 2, and 3 years.

As of right now, the only options when setting the certificate duration is 1, 2, and 3 years. However, if you'd like this duration to be changed, I'd recommend leveraging our User Voice forum and creating a feature request, so our engineering team can look into implementing this.

According to this article, the VPN root certificate (cloud root certificates) created from CA Blade should be added to the on-prem active directory Enterprise NTauth store. Is it a mandatory step? Without even doing so, I can connect to AOVPN without any issues.

This step is mandatory. When it comes to deploying the conditional access root certificates to the on-premises AD, you're deploying the CA root certificate as trusted root certificate for VPN authentication to your on-premises AD.

I hope this helps!

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.

----------

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

JamesTran-MSFT 36,861 Reputation points Microsoft Employee

2022-12-30T17:37:46.26+00:00

@tn57chgs-3733
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.

----------

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.
JamesTran-MSFT 36,861 Reputation points Microsoft Employee

2023-01-09T22:50:25.887+00:00
@n57chgs-3733
Thank you for following up on this and I'll do my best to address your additional questions!

Viewing the VPN certificate within your Test tenant but not Prod:

When looking at this using Global Admin permissions, I wasn't able to see the certificates within my VPN Server's app registration even when I have two certificates created within the VPN connectivity blade. I've reached out to my team on this and will update as soon as possible.

VPN certificate should be deployed immediately to the VPN server:

When it comes to adding the VPN certificate created in the Azure portal to your VPN server. From my understanding this is mandatory/critical step to avoid any issues with the credential validation of the VPN client, since the VPN client uses the Azure AD-issued certificate to authenticate with the VPN server. For more info.

I am interested and also to know the impact is, conditional access for the clients managed by Intune (AzureAD Joined only) and we use our Internal PKI as CA and NDES for certificate enrollment and delivery via Intune to the clients and we use SCEP user certificate.

I'm not familiar with Intune, but I'll add our Intune tag(s) to this thread so their community experts can take a look into this issue as well.

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.
JamesTran-MSFT 36,861 Reputation points Microsoft Employee

2023-01-09T22:51:57.927+00:00

@n57chgs-3733
If you'd like our support team to take a closer look into your issue and environment please let me know, and I can enable a one-time free technical support request for your subscription so you can work with our support engineers to get this issue resolved.

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.
tn57chgs-3733 6 Reputation points

2023-01-18T19:01:39.81+00:00

Thank you very much for your time for answering my questions. FYI (My answers below are highlighted in bold)

Where are these certificates stored and can Global Admins view and manage them?

VPN certificate information such as certificate thumbprint and certificate expiration information, are stored as a service principal named "VPN Server" in Azure AD

As per this article, when we create an app it creates two objects with the same Application ID and different Object ID's, the one that resides under enterprise application blade is nothing but a service principal, and I think the expired or renewed certificates cannot be seen under this location instead it can be seen only under App Registration blade.
Strangely, I have access to two AzureAD tenants one is used in production and another one is used just for testing, I am able to view the certificate from test tenant under (app registration --> VPN server) blade but on my prod tenant, its not showing up there. FYI, I also cross checked, both the objects hold the same application ID and it is indeed the same.

The below one taken from my prod tenant

The below one taken from my test tenant

Please check this out from your side and let me know.

FYI, my account has both [Application Administrator, Cloud Application Administrator] permissions so I believe there won't be an issue with the permission.

Can the duration extend? Right now, it only shows 1, 2, and 3 years?

Thanks. no further comments to this specific question.

According to this article, the VPN root certificate (cloud root certificates) created from CA Blade should be added to the on-prem active directory Enterprise NTauth store. Is it a mandatory step? Without even doing so, I can connect to AOVPN without any issues.?

This step is mandatory. When it comes to deploying the conditional access root certificates to the on-premises AD, you're deploying the CA root certificate as trusted root certificate for VPN authentication to your on-premises AD.

Please help me understand with a scenario because I am not able to catch up.

Under which scenario your statement above is applicable? The scenario I am interested and also to know the impact is, conditional access for the clients managed by Intune (AzureAD Joined only) and we use our Internal PKI as CA and NDES for certificate enrollment and delivery via Intune to the clients and we use SCEP user certificate.

Many Thanks in Advance
tn57chgs-3733 6 Reputation points

2023-01-18T19:01:47.6233333+00:00

Thanks for your prompt response to my previous question.

Viewing the VPN certificate within your Test tenant but not Prod:

Yes, it would be great if you can assign a support engineer to check this issue for me.

VPN certificate should be deployed immediately to the VPN server:

As I mentioned in my previous reply, in order for the WAN Mini SSTP VPN adapter to connect AOVPN, it requires the internal PKI root certificate under trusted root certificate authority and also it requires a user or device authentication either using a certificate (user or device cert) (if smart card chosen in the radius) or MSCHAP then (User credentials), in our case we use SCEP user certificate to authenticate with our NPS server during the handshake, and like I mentioned earlier that it is working fine without having AzureAD VPN root certificate in our on-prem AD trusted store.

According to MS, the same should be added to VPN server when it is a standalone else it should be added "Log on to a domain-joined computer with Enterprise Admin rights and run these commands from an Administrator command prompt to add the cloud root certificate(s) into the Enterprise NTauth store:"

This is the reason why I asked whether it is mandatory to add it to the VPN Server or On-Prem AD and yes you are right that this is how MS mentioned in the VPN deployment article but in reality it behaves different.

Looking forward to your reply and sorry for the late response.
JamesTran-MSFT 36,861 Reputation points Microsoft Employee

2023-01-19T00:20:55.08+00:00
@tn57chgs-3733

Thank you for following up on this!

Can you please email me with the info below, I'll go ahead and enable a one-time free technical support request for your subscription so you can work with our support engineers to get this issue resolved.

<<Removed Email Instructions>>

Thank you for your time and patience throughout this issue!
tn57chgs-3733 6 Reputation points

2023-01-19T00:53:10.35+00:00

As suggested I have sent an email with all the information mentioned by you. Please also answer the below one.

VPN certificate should be deployed immediately to the VPN server:

As I mentioned in my previous reply, in order for the WAN Mini SSTP VPN adapter to connect AOVPN, it requires the internal PKI root certificate under trusted root certificate authority and also it requires a user or device authentication either using a certificate (user or device cert) (if smart card chosen in the radius) or MSCHAP then (User credentials), in our case we use SCEP user certificate to authenticate with our NPS server during the handshake, and like I mentioned earlier that it is working fine without having AzureAD VPN root certificate in our on-prem AD trusted store.

According to MS, the same should be added to VPN server when it is a standalone else it should be added "Log on to a domain-joined computer with Enterprise Admin rights and run these commands from an Administrator command prompt to add the cloud root certificate(s) into the Enterprise NTauth store:"

This is the reason why I asked whether it is mandatory to add it to the VPN Server or On-Prem AD and yes you are right that this is how MS mentioned in the VPN deployment article but in reality it behaves different.

Many Thanks in Advance.
Simon Rae 6 Reputation points

2023-03-01T19:44:13.77+00:00

We are in a similar situation with our root VPN cert expiring in a few weeks. I was wondering if it is required for the AOVPN clients to have the new root cert in the trusted store on their laptops to be able to connect, or is it just needed on the RAS & NPS servers. If it's needed on the client laptops, that poses a bit of an issue, as remote users will not be able to connect to AD to pick up this change as soon as we renew the cert.
Douglas Todd 0 Reputation points

2024-02-08T19:04:23.9433333+00:00

I am in the same boat as you regarding viewing and managing these certificates, though it is for a different reason. Used the option in Entra -> Security -> Conditional Access -> VPN Connectivity to generate a VPN certificate, but I neglected adding it to our Azure VPN Gateway server before the short term certificate expired. Now this GUI option to generate this certificate is missing completely in Conditional Access, and I cannot manage the one that was created. The Enterprise Application exists, but the certificate is not there. I originally generated this certificate 1 month ago via the Conditional Access VPN Connectivity GUI option. In the last month this option has disappeared from this tenant and 5 other tenants that I spot checked. Are we in some kind of rollout of a functionality change that has only applied to some tenants and not others?

Answer 2

dmslw 0

We had this same situation today. The link to the VPN Connectivity Page is missing in the Azure Portal which means you cannot generate a new certificate. We raised this with Microsoft Support, and they confirmed that this is a bug in the portal which is scheduled to be fixed in July 24. The workaround was a link which they provided whch takes you directly to the right page: https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/vpnConfigurationsBlade Hope this helps someone.

Share via

[AzureAD - Conditional Access - VPN Connectivity - Certificate Expired]

2 answers

Your answer