Azure: Private link name resolution for P2S (vWAN) VPN Clients

Goal: disable Public access to Azure KeyVault; enable access via VPN.

Options:

1. Service Endpoint

2. Private endpoint

I selected Private Endpoint, it gives more granular control.

Configuration:

1. Create a Private Endpoint for the Keyvault and publish it to a Private DNS zone.

2. Set up a Private DNS resolver to be able resolving resource names via VPN (its IP address will be used as a Custom DNS for VPN)

3. Add a custom DNS in “VPN Server configuration” of VWAN hub used for VPN (User VPN (Point to site) tab)

4. Link Private DNS zone created in step 1 to vNet where Private DNS resolver resides.

Azure AD: device provisioning package failed with 0x800704f1

I am helping one of my Customers with migration from AD-joined devices to Azure AD joined. The devices are joined to on-prem AD and registered in Azure AD, but non hybrid.

Unfortunately, as per my knowledge, Microsoft does not have a tool for this migration.

It looks like a computer reset (without user data save) and consequent join to Azure AD domain is the only option.

To make it easier for the Customer I create a Provisioning Package doing that. The package has been created in Windows Configuration Designer (WCD) and I put it to a file share. After that I tried to run in manually from a test device. The attempt failed with error: 0x800704f1 and recommendation to talk to the package designer

Resolution: I copied the package to a local drive on the test machine and tried from there – this time it works!. 

Azure: Intermediate CA certificate issue

I am helping with an Azure Application Gateway for one of my Customers. Recently he asked me to update a certificate on the Gateway and provided a .PFX file containing a certificate issued by Digicert.

I updated the certificate and for most of browsers everything looked good, but when one of developers checked compatibility, Mozilla check failed saying Digicert Intermediate certificate requires “additional download”.

SSLChecker (sslhopper.com) gave me a warning:

“The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate. Learn more about this error. You can fix this by following DigiCert’s Certificate Installation Instructions for your server platform. Pay attention to the parts about Intermediate certificates.”

Resolution: I installed the certificate from provided PFX to my local machine and download proper certificate chain from Digicert. After that I exported the certificate to the new PFX selecting “Include all certificates in certification path if possible” option.

After that I replaced the certificate on my App Gateway listener with this one. That fixed the issue.

Here is SSL check before:

And after:

There is a warning about SHA1, but that is related to Digicert Root CA certificate.

Azure AD: Distribution Group–add a member is greyed out

Bumped into an interesting issue – tried to add a user to an existing Azure AD Distribution group (created directly in AAD, not synced) but in GUI “Add Membership” button in the Group property was greyed out.

From the user side an attempt to add the user to the Group failed with: “Unable to complete due to service connection error”

I found an MS Answer doc describing similar issue: Add Member button greyed out on Microsoft Azure Active Directory with proper roles? – Microsoft Q&A

and tried both powershell and MS Graph approach, still the same issue. The error in PowerShell and Graph pointed that the object was created in external source: “Unable to update the specified properties for objects that have originated within an external service.”

Resolution: I succeeded to add a user to the group from Office Admin portal (admin.microsoft.com)

ADFS: Device registration adventure with GMSA account

I decided to set up a Lab environment for Windows Hello for Business. One of commands required on ADFS server is Initialize-ADDeviceRegistration. Syntax for the command is pretty easy, but all my attempt failed with:

Error:

Initialize-ADDeviceRegistration : The specified identity ‘mydomain\myADFSserviceaccount’ could not be found. Some or all identity references could not be translated

Reason: I am using a Managed Account for ADFS, so I need to put “$” at the end of the account name: ‘mydomain\myADFSserviceaccount$’

SCCM: MP is not reachable via CMG (PKI scenario)

One of my Customers asked me to help with a CMG deployment. The idea is to get Internet-based machines managed and patched.

They do not have Hybrid AAD joined environment yet, so I need to use old good PKI.

I decided to get it in my Lab first. I do have CA on my pfsense router to get it even more interesting (the certs do not CRL link).

I issued required certificates for my SCCM, CMG and Clients and flipped my Primary site to PKI. On all Certificate settings I checked “No CRL verification” box (sice I do not have one.

Internally everything worked fine, but when I flipped a Client to “Internet” subnet I found it can connect for a short period of time only. After that connection to MP via CMG is lost, client goes grey and I see:

[CCMHTTP] ERROR INFO: StatusCode=403 StatusText=CMGConnector_Clientcertificaterequired

in LocationServices.log on the Client.

It turned out to be a known issue (KB4503442) or better by design behaviour for a scenario when Azure AD tokens are not in use.

So, I added a Client cert with the name of my MP as Subject Name and in SAN. Restarted Cloud Connector on my SCCM.

Still no go.

Checked the SMS_Cloud_ProxyConnector.log  and found:

Chain build failed cert: 77…………………………………………1

Chain 0 status: RevocationStatusUnknown

ok… So it looks like even though I unchecked Revocation List check in properties of CMG the connector is still trying to check it . In troubleshooting guide (https://support.microsoft.com/en-ae/help/4520150/troubleshooting-co-management-bootstrap-with-modern-provisioning)  Microsoft says the best way is to publish CRL properly (sure, I know that). and do not provide information how to disable the check.

But if we take a look in the registry HKLM\SOFTWARE\Microsoft\SMS\SMS_CLOUD_PROXYCONNECTOR  we can find a key: ClientCertSelectionNoCRLCheck set to 0 by default.

I switched it to 1 and restarted the connector.

After that the Internet Client successfully connected to the MP.

Note: I completely agree with the Vendor – the proper approach is to have your PKI properly configured and CRL published with public access; but in my case it is a Lab, so the workaround is acceptable.

Intune: Remove Microsoft Teams shortcut

I am in the middle of Windows Autopilot project. The Customer wants Microsoft Teams be a part of an Application set we install.

We are also implementing One Drive Known folder Move  (KFM) to redirect desktop to One Drive for Business.

The problem is related to Teams behaviour – it installs its shortcut on a user desktop every time it is installed. As a result we do have multiple Teams shortcuts after each device wipe – Teams creates a shortcut and after that another shortcut is synchronized by KFM from One Drive.

I spent a while, trying to find a solution to disable Teams shortcut creation; but it looks like at that time Microsoft does not provide any policy/registry settings to prohibit that.

So, I decided to delete the excessive shortcut using PowerShell script.   The problem with that is Intune behaviour – it runs a script only once . From my experience KFM kicks on quite a while after the user logon, so PowerShell script being added to the process will just miss it.

After all I decided to create a Win32 application in Intune and set up a detection rule to be sure the App will run (and re-run) when it is required.

Here is the removeshortcut.ps1 script to delete the excessive shortcuts

$DesktopPath = [Environment]::GetFolderPath(“Desktop”) remove-item -path $DesktopPath\* -filter “Microsoft Teams (*.lnk”

Here is install.cmd acting as “Install” in win32 app

powershell.exe -ExecutionPolicy Bypass -command “& ‘.\removeshortcut.ps1′”

Here is detection.ps1 script for win32 application

$DesktopPath = [Environment]::GetFolderPath(“Desktop”) if (-Not (Test-Path -Path “$desktoppath\Microsoft Teams (*.lnk”)) {write-host “missing”}

After that I packaged the “application” using IntuneWinAppUtil.exe tool and created a Win32 Application in Intune (it must be run in User context) and assigned it to a group of Users.

On the first run it successfully removed the shortcuts. I put them back to see when Intune realizes the “application” is not installed and run the command again . Unfortunately, according MS dock re-evaluation will happen in 24 hours…    https://docs.microsoft.com/en-us/intune/apps-add

Intune: Configure Intune NDES Connector to get User certificates from Digicert (Symantec) Web Services

One of my Customers moving everything to Azure decided to replace internal Microsoft PKI with a managed solution from Digicert (Digicert bought Symantec certificate business recently).

At the present time Microsoft has an article describing Intune Configuration with Symantec PKI Manager Web Service: https://docs.microsoft.com/en-us/intune/certificates-symantec-configure

Unfortunately, it is not very clear what needs to be configured on Symantec (sorry, Digicert) side and I spent some time to get it working.

So, first of you need to talk to Digicert and get a Managed PKI environment.

After that, as per the article, generate a managed certificate and deploy your Managed PKI environment Root cert using Intune. It should be easy.

I took this certificate:

After that you need to add  a certificate profile on Symantec side (MS article does not provide any details on it):

I select Client Authentication (User)

Give your template a friendly name, select a PKI Web Services as Enrollment method and click Advanced Options:

Now we need to do an interesting trick. It is in “Troubleshooting” section of Microsoft article and apparently is required if your UPN have a special characters. I need it even though my UPN did not have them… So:

– Click Add field and select Common Name (CN) and Webservice Request. That will create a new Common Name tab at the bottom. DO NOT click Save

– Delete the old Common Name (CN) at the top of the list.

– You can customize other parameters. For example, I added an email as a Subject Alternative Name

– Now you can save

Copy Certificate Template OID, you will need it for Intune:

At this point you can Download/Install Intune Connector. The procedure is described well in the Microsoft article.

When the connector is up:

you can create an Intune PKSC 10 profile (I also added EKU even though it is not in the doc):

Save the settings, click Create the profile and assign it to a group of users.

After Intune policy update the certificate should be requested by Intune on a Client behalf and deployed to your device:

SCCM: CMG Provisioning Failed

Microsoft published an interesting Lab Set for Modern Desktop Management. Between projects I decided to install the kit and try Labs.

Here are some gotchas:

1. If Azure Account does not have an Azure Subscription in its own directory CMG installer cannot see the Subscription. Even if the account has rights to another subscription. I needed to create a new rial subscription linked to the same AAD to be able to proceed.

2. Even after that CMG provisioning failed. I checked the logs and found that Microsoft decided to not register Classic Compute (yes, CMG still uses Classic model). TO fix that I ran Powershell in Azure Portal and register requred provider:

register-azurermresourceprovider –providernamespace “Microsoft.ClassicCompute”

will see what additional surprises MS prepared…

Azure: Deploy One Drive Known Folder Move with Intune

I am preparing for an Autopilot project for one of my Customers. Microsoft recommends to use One Drive for Business for User data migration.

I tried a couple off approaches how it can be achieved with Intune:

1. Using OMA-DM as per Deploy OneDrive KFM with Microsoft Intune OMA-URI

2. Using Powershell Management Extension: How to deploy OneDrive Known Folder Move with Intune

Both approaches are working; personally I prefer OMA-DM hoping Microsoft will add this option to a standard profile options.