Attempting to restrict access to Citrix ADC / NetScaler Gateway for a nested domain users group does not work

Problem

I was recently asked by a colleague of mine who was setting up Search Filter on a Citrix ADC / NetScaler Gateway so that only users of a Active Directory group could log into the published portal. The Citrix article that demonstrates the configuration is the following:

How to Restrict Access to NetScaler Gateway for only Members of one Active Directory Group
https://support.citrix.com/article/CTX111079

The article is very straight forward and he wanted to use the configuration that allowed for nested groups as describes here:

Nested Groups - By default, NetScaler will only search for usernames that are direct members of the Active Directory group. If you want to search nested groups, then add the Microsoft OID :1.2.840.113556.1.4.1941: to the LDAP Search Filter. The OID is inserted between memberOf and = as shown below:
memberOf:1.2.840.113556.1.4.1941:=CN=Citrix Remote,OU=Citrix,DC=corp,DC=local

So he proceeded to add 1.2.840.113556.1.4.1941 after the memberOf then added the domain users group into the Active Directory group he was going to use to restrict access.

He tested the configuration but noticed that it didn’t work. Reviewing the aaaa.debug logs shows that correct group is being used to filter (I will paste the full debug log at the bottom of this post:

/home/build/rs_130_36_15_RTM/usr.src/netscaler/aaad/ldap_common.c[1332]: ns_ldap_search 0-161: Searching for <<(| (objectClass=domainDNS) (& (sAMAccountName=tluk@contoso.com) (memberOf:1.2.840.113556.1.4.1941:=cn=ACL - Citrix Access,OU=Access Groups,OU=Groups,OU=contoso,DC=corp,DC=contoso,DC=com)))>> from base <<dc=corp,dc=contoso,dc=com>>

However, the test login with tluk@contoso.com which is in the domain users group that is placed in the Citrix Access group eventually fails with:

/home/build/rs_130_36_15_RTM/usr.src/netscaler/aaad/ldap_drv.c[509]: receive_ldap_user_search_event 0-161: User tluk@contoso.com not found on the LDAP server

Sat Oct 3 12:36:22 2020

Attempting to configure the Nested Group Extraction configuration as demonstrated in the following KB does not work:

How to Configure LDAP Nested Group Extraction on NetScaler Gateway
https://support.citrix.com/article/CTX216282

Solution

The short answer to this problem is that attempting use Domain Users to nest into a group used by the Netscaler to filter access will not work because this group is almost certainly configured as the Primary Group of the users and such a group is not used for group extraction. The following is the explanation described by Citrix:

Active Directory Group Extraction Does Not Work on NetScaler
https://support.citrix.com/article/CTX135603

Problem Cause

The Active Directory group which was set as primary group is not used for group extraction. All the other groups associated with the user account are extracted. This is not a bug or issue on a NetScaler appliance. This is as per Active Directory design. Active Directory does not return its primary group as a group therefore the primary group cannot be extracted by a NetScaler appliance. This is true even if you make the Department group as a primary group instead of Domain users. In the search filter on the NetScaler LDAP search filter column you might have to modify the search rule as follows:
memberof=CN=domain users,dc=lab, dc=sumagee, dc=com

Because the primary group is dept only, Domain Users group is extracted by the NetScaler appliance.

It would be nice if this was included in the original KB demonstrating the configuration as this may not be obvious to administrators configuring the restrictions so I hope this post will help anyone who may encounter this scenario.

Enabling user for Teams Enterprise Voice fails with: "Management object not found for identity"

Problem

You’ve signed into Office 365 with the appropriate PowerShell modules and cmdlets:

Import-Module SkypeOnlineConnector

$sfbSession = New-CsOnlineSession

Import-PSSession $sfbSession

… and proceed to use the Set-CsUser cmdlet to enable a user for Teams Enterprise Voice but it fails with the following error:

PS C:\> Set-CsUser -Identity mesheiah@contoso.com -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+7324

Management object not found for identity "mesheiah@contoso.com".

+ CategoryInfo : NotSpecified: (:) [Set-CsUser], ManagementException

+ FullyQualifiedErrorId : Microsoft.Rtc.Management.AD.ManagementException,Microsoft.Rtc.Management.AD.Cmdlets.SetO

csUserCmdlet

+ PSComputerName : admin0b.online.lync.com

The user being enabled for Teams Enterprise Voice has been previously enabled for an on-premise Skype For Business Enterprise Voice so you use the following cmdlet to list the uri properties and notice that the LineURI is still configured with the on-premise deployment:

PS C:\> Get-CsOnlineUser -Identity mesheiah@contoso.com | FL *uri

OnPremLineURI :

LineServerURI :

LineURI : TEL:+14165555555;ext=1324

Including the OnPremHostingProvider to the cmdlet will display the following SRV: value for it:

Attempting to use the Set-CsUser cmdlet to configure the LineURI to null will fail:

PS C:\> Set-CsUser -Identity mesheiah@contoso.com -LineURI $null Unable to set "LineURI". This parameter is restricted within Remote Tenant PowerShell.

+ CategoryInfo : InvalidArgument: (:) [Set-CsUser], ManagementException

+ FullyQualifiedErrorId : LineURI,Microsoft.Rtc.Management.AD.Cmdlets.SetOcsUserCmdlet

+ PSComputerName : admin0b.online.lync.com

PS C:\>

You’ve confirmed that the user has been removed from the on-premise Skype for Business Server.

Solution

One of the possible reasons why this error would be thrown is if the user account still has the msRTCSIP-DeploymentLocator attribute populated with the SRV: value:

This attribute and its value is required for the on-premise Skype for Business configuration but would prevent the user account that is synced into Azure AD to be enabled for Teams Enterprise Voice. To correct the issue, simply open the properties and Clear the value:

Issue a synchronization between the on-premise AD and Azure AD:

Start-ADSyncSyncCycle -PolicyType Delta

Wait for a few minutes and the account should have the LineURI and OnPremHostingProvider attributes empty.

Proceeding to enable the account for Enterprise Voice will now complete.

PowerShell script to extract ObjectGUID, convert to Base64 encoded string, and assign immutableID for Azure AD account for hard matching with AD Connect

I recently had a client who used Office 365 for Exchange Online and Teams while also having an on-premise Active Directory but did not appear to have AD Connect deployed to synchronize their on-premise Active Directory accounts with their Office 365 Azure AD accounts. This became a problem when we started the WVD deployment so the client agreed to have us focus on synchronizing the two directories before commencing with other planned projects.

Azure AD Connect Soft Match vs Hard Match

As some may already know, there are two ways of matching accounts in on-premise Active Directory and Azure AD:

1. Soft Match
2. Hard Match

Soft Match uses the properties of userPrincipalName and ProxyAddresses to determine (evaluated by Azure AD) whether an account in the on-premise Active Directory can be merged with an Azure AD account. This essentially means that if an account is found to have the same userPrincipalName or the same primary SMTP address of ProxyAddresses, then AD Connect will merge the two accounts.

More information about ProxyAddresses matching with the primary SMTP address can be found here:

How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization
https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-match-on-premises-user-accounts-to-office-365

Hard Match uses the property sourceAnchor/immutableID to match the on-premise Active Directory account to the Office 365 account. The default sourceAnchor that Azure AD Connect uses for the on-premise Active Directory is the objectGUID property and the immutableID property is a value assigned to the Azure AD user account. To perform a Hard Match between two accounts, we would set the immutableID property of the existing user in Azure AD to the Base64 encoded string of the ObjectGUID of the user in the on-premise AD.

More information about soft and hard match can be found here:

Azure AD Connect: When you have an existing tenant
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#sync-with-existing-users-in-azure-ad

The Problem

The plan for merging the accounts between on-premise and the cloud was to use the soft match method and the initial test with a newly created account worked without any issues. However, proceeding to accounts that have existed in the on-premise Active Directory would consistently throw a Duplicate Attributes and AttributeValueMustBeUnique error in the AD Connect export job. After reviewing the KB article below without finding a resolution, I decided to proceed with the hard match method.

Troubleshooting Errors during synchronization
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sync-errors

The immediate issue I had with the hard match method was that it required a lot of manual labour to extract the ObjectGUID from the on-premise AD account, convert it to a Base64 encoded string, then import it into the Azure AD account’s immutableId attribute.

Extract Immutable ID

$UPN = "jsmith@contoso.com"

$user = Get-ADUser -Filter 'UserPrincipalName -eq $UPN'

$name = $user.name

$immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

Import Immutable ID

Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId <convertedObjectGUID>

Having to perform the above for 50, 500 or 5000 and more accounts would not be efficient.

Solution

As with many laborious tasks in technology, the best way to minimize the amount of manual labour is to script the process and the following demonstrates this.

Step #1 – Extracting accounts in on-premise Active Directory

We will need to first obtain a list of users we’ll be hard matching with the accounts in Azure AD. If you are matching accounts that are nicely organized in OUs, you can use the following PowerShell cmdlet to export them into a CSV file:

Get-ADUser -Filter * -SearchBase "OU=Toronto,OU=Contoso-Users,DC=contoso,DC=com" -Properties * | Select-Object name,UserPrincipalName,emailaddress | export-csv -path c:\temp\Toronto.csv

The PowerShell cmdlet above will export all of the accounts in the specified OU with the fields:

1. Name
2. UserPrincipalName
3. emailAddress

Repeat the above for any other OUs that need to be matched.

Step #2 – Extracting accounts in Azure AD

The environment I worked in did not consistently have mirroring accounts in the on-premise Active Directory and Azure AD so I decided to export the list of accounts in Azure AD to compare in a spreadsheet:

Get-MsolUser | Select-Object DisplayName,UserPrincipalName,@{Name=’ProxyAddresses’;Expression={[string]::join(“;”, ($_.ProxyAddresses))}},ImmutableId | export-csv -path c:\temp\Toronto-MSOL.csv

Step #3 – Compare the accounts in on-premise AD and Azure AD

With the two CSV files extracted, I placed the UPNs into an Excel spreadsheet and used Home > Conditional Formatting > Highlight Cells Rules > Duplicate Values feature to identify which accounts have matching ones in the other directory.

Step #4 – Extract on-premise AD accounts’ ObjectGUID and Convert to ImmutableID

Now that we have a list of UPNs for users who we intend on matching from the on-premise Active Directory, proceed to create a txt file with just the UPNs separated by line breaks and use the following PowerShell script to extract the ObjectGUID then convert the value to Base 64 so it can be assigned as the immutableID:

foreach ($UPN in Get-Content C:\temp\TorontoAccounts.txt) {

$user = Get-ADUser -Filter 'UserPrincipalName -eq $UPN'

$name = $user.name

$immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

#$UPN,$name,$immutableid

#Store the information from this run into the array

[PSCustomObject]@{

UPN = $UPN

Name = $name

ImmutableID = $immutableId

} | Export-Csv C:\temp\UPNsWithImmutableID.csv -notype -Append

}

Step #5 – Import the UPNs with ImmutableIDs into Azure AD

The final step in this process is to use the CSV created in step #4 to assign the immutableIDs to the identified UPNs in Azure AD with the following script:

$onPremADUsers = Import-Csv c:\temp\UPNsWithImmutableID.csv

foreach ($row in $onPremADUsers)

{

#$row.UPN, $row.Name, $row.ImmutableID

Set-MsolUser -UserPrincipalName $row.UPN -ImmutableId $row.ImmutableID

}

The above will read the CSV file and assign the immutableID.

Step #6 – Confirm that the ImmutableIDs have been assigned

The last step, which is more of a verification step, is to review the UPNs that were assigned with the immutableIDs:

$onPremADUsers = Import-Csv c:\temp\UPNsWithImmutableID.csv

foreach ($row in $onPremADUsers)

{

Get-MsolUser -UserPrincipalName $row.UPN | Select-Object DisplayName,UserPrincipalName,ImmutableId

}

Hope this helps anyone who is looking for a quicker way of extracting and assigning sourceAnchor/immutableID so AD Connect can hard match accounts.

Attempting to set immutableId for user throws the error: "Set-MsolUser : Uniqueness violation. Property: SourceAnchor."

Problem

You’re attempting to use the Set-MsolUser cmdlet to configure the immutableId attribute for a user in Azure Active Directory but receive the following error:

PS C:\> Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId "zxGeOiOTdkivMtgkOsuvKA=="

Set-MsolUser : Uniqueness violation. Property: SourceAnchor.

At line:1 char:1

+ Set-MsolUser -UserPrincipalName jsmith@contoso.com -ImmutableId ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Set-MsolUser], MicrosoftOnlineException

+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UniquenessValidationException,Microsoft.Onlin

e.Administration.Automation.SetUser

PS C:\>

Reviewing the properties of the user account that you are trying to assign the immutableID value to confirms that it is null:

Get-MsolUser -UserPrincipalName jsmith@contoso.com | FL immutableId

Using Get-MsolUser to search for an account with the immutableID does not return any results:

Get-MsolUser | Where-Object {$_.ImmutableId -eq "zxGeOiOTdkivMtgkOsuvKA=="} | select UserPrincipalName

Solution

One of the most common reasons I’ve found for this error is if a deleted user object has the same immutableID assigned to it. A typical scenario would be:

1. An effort was made to merge on-premise Active Directory accounts with Azure AD but Azure AD Connect created a new account with a random number following the name rather than merge the two accounts
2. The administrator deletes the new account and attempts to assign the ObjectGUID (converted to base 64) of the on-premise Active Directory account to the Azure AD account

To confirm whether there is an account in the deleted users container, execute the following cmdlet:

Get-MsolUser -ReturnDeletedUsers

The following cmdlet can return the UPN along with the immutableID of the user accounts found in the deleted users container:

Get-MsolUser -ReturnDeletedUsers | FL UserPrincipalName,immutableID

Once the account with the conflicting immutableID is identified, the following cmdlet can be used to delete it:

Remove-MsolUser -UserPrincipalName jsmith@contoso.com -RemoveFromRecycleBin

With the account removed, you should now be able to assign the immutableID.

Browsing a Citrix ADC / NetScaler published Exchange OWA displays the warning message: Your connection is not fully secure Your connection is not fully secure NET::ERR_SSL_OBSOLETE_VERSION

Problem

You’ve received reports that browsing a Citrix ADC / NetScaler published Exchange OWA displays the following warning message in Chrome and Edge Chromium:

Google Chrome

Your connection is not fully secure

This site uses an outdated security configuration, which may expose your information (for example, passwords, messages, or credit cards) when it is sent to this site.

NET::ERR_SSL_OBSOLETE_VERSION

Edge Chromium

Your connection isn't secure

This site uses an outdated security configuration that might expose your personal information when it's sent to this site (for example, passwords, messages, or credit cards).

NET::ERR_SSL_OBSOLETE_VERSION

It is possible to proceed in both browsers but a Not secure message will be displayed in the address bar:

Solution

One of the reasons why this warning message would be displayed is because Google Chrome 72 and later versions have deprecated support for legacy TLS versions, which include TLS 1.0 and 1.1. If the Load Balancing Virtual Server for the Exchange OWA configured on Citrix ADC / NetScaler has only TLS 1.0 and TLS 1.1 enabled as shown in the screenshot below then the warning message above will be displayed:

To correct the issue, simply enable TLSv12 in addition to TLSv1, TLSv11:

Or just enable TLSv12 if there are no legacy devices with browsers accessing the website (those should be upgraded if they exist):

Once updated, the site should load and the Security tab of Google Chrome’s Developer Tools should display a message indicating the site is using TLS 1.2:

HTTP ERROR 440 is displayed when using AD FS claims-based authentication with OWA (Outlook on the Web)

Problem

You have AD FS (Windows Server 2019) claims-based authentication configured for Exchange Server 2019 Version 15.2 (Build 464.5) OWA (Outlook on the Web) and has had it working in production for months but received complaints from users that the following error is presented after successfully authenticating at an AD FS portal to access OWA:

This page isn’t working
If the problem continues, contact the site owner.
HTTP ERROR 440

Attempting to access /ECP also throws the same error.

This appears to only happen in Chrome but not Internet Explorer or Chromium Edge (or regular Edge).

The following are versions of Chrome that presents the error above:

Version 85.0.4183.121 and 86.0.4240.75

The following are the version of IE and Edge Chromium that did not exhibit this issue:

Edge Chromium: 85.0.564.70

Internet Explorer 11: 11.1082.18362.0

Solution

A quick search for this issue on the internet returned the following thread on Reddit:

https://www.reddit.com/r/exchangeserver/comments/iyirls/owa_440_error_in_chrome/

It appears the quickest way to load the page in Chrome is to navigate to the following setting:

chrome://flags/#reduced-referrer-granularity

Then set the Reduce default ‘referrer’ header granularity. From default to disable:

This can also be configure via Group Policy via the registry as shown in the following document: https://cloud.google.com/docs/chrome-enterprise/policies?policy=ForceLegacyDefaultReferrerPolicy

Having worked with a lot of clients to implement missing security headers identified by the following popular scan by Scott Helme: https://securityheaders.com/, I felt that there must be a better way of addressing this at the AD FS server level rather than the client level. The Referrer Policy header was familiar to me because I had recently implemented for another client’s Citrix portal and for those who are not familiar with it can find more information at Scott Helme’s site: https://scotthelme.co.uk/a-new-security-header-referrer-policy/

The short description of it as described by Scott is: Referrer Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.

After reviewing the authentication and redirect process between the AD FS portal and OWA, then testing the various Referrer Policy options, it appears the most restrictive one that worked was the no-referrer-when-downgrade because the full URL was passed with this option.

The following is the official Microsoft documentation that explains how headers are configured for AD FS:

Customize HTTP security response headers with AD FS 2019
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/customize-http-security-headers-ad-fs

The document does not include the Referrer Policy in the list but you can view and configure it as shown in the following cmdlets executed on the AD FS server:

To view the response headers:

Get-AdfsResponseHeaders

To expand the truncated list of response headers:

PS C:\> Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders

Key Value
--- -----
Strict-Transport-Security max-age = 31536000
X-Frame-Options DENY
X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
Content-Security-Policy default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src *.duosecurity....

PS C:\>

To configure the Referrer Policy:

Set-AdfsResponseHeaders -SetHeaderName "Referrer-Policy" -SetHeaderValue "no-referrer-when-downgrade"

Confirm that the Referrer-Policy is configured with the following cmdlet:

Get-AdfsResponseHeaders | Select -ExpandProperty ResponseHeaders

Key Value
--- -----
Strict-Transport-Security max-age = 31536000
X-Frame-Options DENY
X-Content-Type-Options nosniff
X-XSS-Protection 1; mode=block
Content-Security-Policy default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src *.duosecurity....
Referrer-Policy no-referrer-when-downgrade

To remove the Referrer Policy:

If the Referrer-Policy needs to be removed then the following cmdlet can be executed:

Set-AdfsResponseHeaders -RemoveHeaders "Referrer-Policy"

Enabling the Microsoft Teams Calendar button for users with on-premise Exchange mailboxes

One of the more common questions I’ve been asked by colleagues and clients over the past few months is in regards to integrating Microsoft Teams with an on-premise Exchange mailbox so that users could access their calendars within the Teams client. Without a supported on-premise Exchange or hybrid configuration, the Teams client will not display the Calendar button. Given the frequency of this issue, I would like a write a quick post for items to check if the Calendar button is not present.

The following is the official documentation of the requirements to verify:

Requirements to create and view meetings for mailboxes hosted on-premises
https://docs.microsoft.com/en-us/microsoftteams/exchange-teams-interact#requirements-to-create-and-view-meetings-for-mailboxes-hosted-on-premises

If mailboxes are hosted on-premises, to create and view meetings, the following requirements must be met:

1. The required Teams license needs to be assigned for the Azure Active Directory synced user.
2. Users must be synchronized to Azure Active Directory. For information about how to use Azure AD Connect to synchronize with Azure Active Directory, see Hybrid identity documentation.
3. Mailboxes are hosted in Exchange Server 2016 Cumulative Update 3 or later.
4. Autodiscover and Exchange Web Services is published externally.
5. OAuth authentication is configured preferably via the Exchange Hybrid Configuration Wizard running a full hybrid configuration (Classic or Modern). If you are not able to use the Hybrid Configuration Wizard, configure OAuth as described here: https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help.

Note Exchange trusts OAuth Token from Teams service which is known as EvoSTS. Step 1 should be enough, but just the EvoSTS; ACS is used for Free/Busy lookup in the calendar.

1. The checkbox for the Exchange Hybrid Deployment feature in Azure AD Connect is set.
2. For calendar app support and Teams Outlook Add-In for Mac, Exchange Web Service URLs must be configured as SPNs in Tenant Azure AD for the Exchange Service Principal. This step is done with Hybrid Configuration Wizard or following manual steps for Hybrid Modern Authentication.

In short, verify the following:

1. A Teams license must be assigned to the user (this can’t be missed as the user wouldn’t be able to log on without one)
2. Verify that the on-premise account for the users are synced into Azure AD (do not have separate on-premise and cloud accounts or there would be no way for Teams to know they are linked).
3. I have not been able to get the calendar feature to work with any Exchange versions earlier than 2016 CU3 (check your Exchange version here: https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019)
4. Autodiscover and EWS should already be published if mailbox via internet access is allowed but if it isn’t, make sure these services are published and tested with https://testconnectivity.microsoft.com/
5. There are two ways to configure OAuth authentication:

a) Use the Exchange Hybrid Configuration wizard via the on-premise Exchange EAC:

b) Or manually via this link: https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help

It is very unlikely that you need to use the link to manually configure it so use the Exchange Hybrid Configuration wizard to configure this.

6. Verify that the follow checkbox for the Exchange Hybrid Deployment feature in Azure AD Connect is enabled:

7. This step is the same as step #5 and I would recommend to use Exchange Hybrid Configuration wizard for the configuration.

I’ve found that the calendar button can take upwards to a few hours if I had just enabled the Exchange Hybrid Deployment for AD Connect so be patient. Once all the requirements above have been met, you should see the calendar button in the Teams client as shown below:

Successfully authenticating with Citrix ADC / Netscaler Gateway displays the error: "Http/1.1 Internal Server Error 43531"

I recently ran into an issue with a Citrix ADC / NetScaler NS13.0 36.27.nc after a reboot where the following error is displayed upon successfully authenticating:

Http/1.1 Internal Server Error 43531

The URL displayed ends with /cgi/dlge:

https://workspace.contoso.com/cgi/dlge

No configuration changes have been made for months. I combed through the configuration but could not determine why this error was being thrown so a ticket was opened with Citrix. The engineer went through the configuration and decided to change the Web Interface Address FQDN in the Citrix Gateway Session Profile to use the IP address instead of the DNS of the StoreFront server as shown in the screenshot below, which immediately corrected the issue:

We originally thought that there was something wrong with DNS but a DIG for the storefront.contoso.com URL returned the correct IP address for the Load Balancing Virtual Server that load balanced the two StoreFront servers:

root@CTXNETSCALER# dig storefront.contoso.com

; <<>> DiG 9.10.6 <<>> storefront.contoso.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31561

;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1280

;; QUESTION SECTION:

;storefront. contoso.com. IN A

;; ANSWER SECTION:

storefront. contoso.com. 3600 IN A 10.0.1.17

;; Query time: 0 msec

;; SERVER: 127.0.0.2#53(127.0.0.2)

;; WHEN: Tue Sep 29 19:25:36 UTC 2020

;; MSG SIZE rcvd: 69

root@CTXNETSCALER#

I haven’t gotten to the root cause of this issue but noticed that there were no recent posts for this error and thought I’d write a post in case someone else encounters this issue. We were told that an upgrade from the current version 13 Build 36.28 to version 13 Build 64.35 would resolve the issue so I will update this post when I determine whether it resolves the issue.

Configuring a GPO to permit a MMC snap-in that is not available in the list of "Restricted/Permitted snap-ins" provided by the default Microsoft Management Console policy setting

Problem

There are situations where an existing GPO is configured to restrict users from launching the MMC and the available snap-ins for non-administrative users to enhance security. To achieve this, an administrator can create a GPO with the following settings:

User Configuration > Administrative Templates > Windows Components > Microsoft Management Console > Restrict users to the explicitly permitted list of snap-ins: Enabled

Re-enabling select MMCs are fairly straight forward as a list of consoles are provided in the sub folder: Restricted/Permitted snap-ins

As the list provided in the default Group Policy ADM only includes default Windows Server snap-ins, attempting to add a MMC such as the following SQL Server 2919 Configuration Manager would become a problem:

Solution

There are two methods to address this issue. The first is to create a custom ADMX file and import it into Active Directory and the second is to apply the registry key that a custom ADMX would. This document serves to demonstrate the latter method as it is simpler for one-off configurations. To achieve this, we will need to create a GPO that will create a [HKCU]\Software\Policies\Microsoft\MMC\{MMC snap-in GUID} and set the Restrict_Run key to 0, which represents enable (1 is disabled):

Identify the custom MMC snap-in GUID

The first step is to identify the custom mmc snap-in GUID. For the purpose of this example, we will use the snap-in SQL Server 2919 Configuration Manager. Begin by navigating to:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\

Then locating and copying the custom snap-in’s GUID, which is the folder’s name:

{84a016c0-5617-4a05-ae8c-c806c5ff3e20}

Create a GPO with an update registry configuration

With the mmc snap-in GUID identified, proceed to create a GPO, navigate to User Configuration > Preferences > Windows Settings > Registry:

Create a registry configuration as such:

Action: Update
Hive: HKEY_CURRENT_USER
Key Path: Software\Policies\Microsoft\MMC\{84a016c0-5617-4a05-ae8c-c806c5ff3e20
Value name: Restrict_Run
Value type: REG_DWORD
Value data: 0

The policy should look as such once configured:

With the above policy created, have the user with this policy applied log off and back on to access the custom mmc snap-in.

Export a certificate that does not allow the private key to be exported from a Windows Server

I recently had a client who inadvertently created and completed a certificate request on a Windows Server that did not allow the private key of the certificate to be exported and needed it to be exported with the private key so it could be placed on another server.

While this is likely a common issue, I haven’t personally come across it so wasn’t familiar with the options available. A quick search on the internet returned a few different methods and the first one I tried actually triggered the antivirus to block the utility. The second method I found ended up working so this post serves to demonstrate the process.

Begin by downloading the following Exporting Non-Exportable RSA Keys utility from GitHub:

https://github.com/luipir/ExportNotExportablePrivateKey/tree/fca10bf0807fe8160502d448d22537e499c3c8d5

As well as the following well known PsTools:

https://docs.microsoft.com/en-us/sysinternals/downloads/pstools

Unpack exportrsa utility and PsTools into the directories of your choice on the server with the certificate to be exported with the private key, launch the command prompt as an administrator, change the directory to where PsTools was unpacked and execute:

PsExec64.exe -s -i cmd

Change the directory to where exportrsa was unpacked and execute exportrsa.exe in the exportrsa\release folder:

The utility will cycle through certificates found in the Local Computer certificate an allow you to export the private key:

The exported PFX will be placed in the exportrsa.exe directory: