IT Consultant Everyday Notes

Just some problems/solutions storage

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: CMG installation failed when granting permissions to a resource group

I reinstalled a Cloud Management Gateway (CMG) in my Lab and the installation failed with: “Error occurred when granting Contributor permission to the Azure AD app for resource group RG-SCCM-CMG. For more information, see SmsAdminUI.log”

I checked the log and found a weird error containing the following (tenant are sanitized):

“InvalidAuthenticationTokenTenant: The access token is from the wrong issuer ‘https://sts.windows.net/TENANT1/’. It must match the tenant ‘https://sts.windows.net/TENANT2′ associated with this subscription. Please use the authority (URL) ‘https://login.windows.net/TENANT1′ to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later”

Strange, taking in consideration the account I used to sign in has only one directory associated.

Resolution: I closed SCCM console and completely deleted cache including cookies in my Edge Browser. After that I restarted the installation from SCCM console and this time it passed smoothly.

SCCM: Secondary SUP broke the primary one.

Recently I helped my Customer with a CMG configuration. The Clients are not hybrid joined, so we needed to use PKI infrastructure. For the Pilot the Customer decided to bring a new 2016 Server and configure it for SSL-enabled MP and SUP in the current HTTP environment (SCCM is installed on Windows Server 2012 R2).

Everything looked ok until the second SUP was prepared. We used https://www.windowsmanagementexperts.com/configmgr-add-second-software-update-point/configmgr-add-second-software-update-point.htm as a guide and pointed the new WSUS to the primary database. That was a mistake – the secondary WSUS was installed ok, but the primary went down and could not start anymore. I tried to run wsusutil postinstall  with specified content folder and database, but WSUS was not happy anyway. wsusutil log revealed that the new 2016 WSUS actually updated WSUS DB schema and the old 2012 R2 WSUS could not access it anymore Smile. The error message suggested to upgrade WSUS to the same version…

Hopefully we had a backup of the DB, so I deleted the new WSUS, restored the DB with the old schema and re-run wsusutil postinstall content_dir=*MYFOLDER*  SQL_Instance_Name=*MySQLNAME*. After that the primary WSUS started and with some time SUP connected to it correctly.

After that I install a new WSUS on the 2016 server again, but this time I used a local folder for content and WID for the WSUS database. Next, I moved database from WID to my SQL server with a different name (since SUSDB already existed there) and tweaked registry settings in WSUS Server configuration to point it to the new location. step-by-step is here: https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/manage/wid-to-sql-migration

registry settings for SQL name and DB name (if the name was changed):

image

Lesson learned: it is always better to use the same OS version for site systems in your SCCM infrastructure.

SCCM: Client certificate issue

I added an SSL MP/SUP in my lab environment and move a test client to the associated subnet. Unfortunately, the client did not register itself and the Client had “Self-Signed” certificate in SCCM Client General Properties. MP was switched correctly.

MP_Registration_Manager.log on the new MP showed:

“The certificate chain processed correctly but terminated in a root certificate not trusted per ConfigMgr CTL.”

I checked certificate storage on the new MP and found my Root certificate not only under “Trusted Root Certification Authorities” but also under “Intermediate Certification Authorities”. Not sure how SCCM put it there, but I deleted them in “Intermediate …” folder. After several minutes the client registered successfully.

SCCM: Edge Chromium installation failed with 1(1x)

With SCCM (MEMCM) 1910 we can create Edge deployment directly from SCCM console the same way as O365 (even though the old .MSI is still working).

Sounds like a nice idea. I created a deployment (here is a nice outline: https://stevenbart.com/en/2020/01/09/deployer-microsoft-edge-chromium-au-travers-de-configuration-manager/) and saw a new Application “Edge Deployment” under Applications node in SCCM.

I refreshed computer policies on a Client and manually started “Edge Deployment” Application installation from Software center. It miserably failed.

After digging fresh logs I found:

in AppEnforce.log

Unmatched exit code (1) is considered an execution failure

Long story short: Microsoft uses a PowerShell script for the .msi installation. Even though the script is signed, the default Powershell Execution POlicy (Restricted) does not allow that. So you need either relax the policy to “Remote Signed” at least or add –ExecutionPolicy Bypass clause to the installation command in your deployment type(s) like this:

image

After that update machine policy on your test client and start the installation again. At least that fixed the issue for me.

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 Smile. 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.


PKI: Active Directory Web Service (ADWS) logs Event ID 1400 after changing DC certificate from “Domain Controller” template to “Kerberos Authentication” template.

Microsoft recommends using “Kerberos Authentication” template for Domain Controllers instead of older “Domain Controller” and “Domain Controller Authentication” templates https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki

we can easily do so creating a duplicate of “Kerberos Authentication” template and set up a superseding for templates issued based on older templates.

One of my Customers complained that when he did so, Active Directory Web Services (used, for example for remote Power Shell connect) started to log a Warning (Even Id 1400), regardless the fact the certificate has proper EKU and the server FQDN is included in subject name (as DNS name as it is described in the article) and in SAN.

image

Event Id: 1400

Active Directory Web Services could not find a server certificate with the specified certificate name. A certificate is required to use SSL/TLS connections. To use SSL/TLS connections, verify that a valid server authentication certificate from a trusted Certificate Authority (CA) is installed on the machine.
Certificate name:

It is important to note that by default “Kerberos Authentication” template has Subject name set to None as per RFC 3280, so he customized the template duplicate and put “DNS name” under “Subject name format”.

Resolution:

I created a new duplicate of the Kerberos Authentication template (Server 2003 Compatibility level!!!) and add a Common Name to the Subject Name field

image

after that I added the template to my CA and requested the template-based certificate from my Domain Controller. I removed the old certificatee to keep just one certificate in the Local machine store.

image

After after restart ADWS successfully recognized the certificate (Even Id 1401).

imageNote: Microsoft has an article saying the empty Subject name is fine from RFC point of view, but that can cause issues with third-party apps… It looks like not only with third party Smile

Intune: RemoteWipe fails to execute on Windows 10 client with "The request is not supported"

Another surprise from Intune – I tried to Wipe a Win 10 Client remotely from Intune Console and it failed with abovementioned error on the Client.

There are a couple of articles related to what can cause that Smile

https://support.microsoft.com/en-hk/help/4034985/intune-remotewipe-fails-to-execute-on-windows-10-client-with-the-reque

and

https://support.microsoft.com/en-ca/help/4039769/remotewipecommandfailstoexecuteonwindows10clientwiththerequestisnotsup

but my case was not documented – I had an encrypted data drive connected to my test VM. (I tested Bitlocker on data drives). As soon as I removed the drive and refreshed the policy the device was wiped.

I am wondering what if I will have the situation in prod and the drive removal is not an option?????

Interesting enough that FreshStart AKA CompleteWipe works just fine….

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 Smile. 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 Smile . Unfortunately, according MS dock re-evaluation will happen in 24 hours… Sad smile   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:

image

image

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

image

image

I select Client Authentication (User)

image

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

image

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.

image

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

image

– Now you can save

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

image

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

When the connector is up:

image

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

image

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:

image