With more of our customers moving to secure Windows enterprise deployments, separating user and resources objects in Active Directory is one architectural decision they consider. This model can provide service isolation to protect certain segments of an organization.
As a consultant on the Citrix Consulting Public Sector team, I’ve worked with many organizations that are integrating Citrix solutions into complex Active Directory infrastructures that leverage this isolation model. In this post, I’ll share implementation guidance on deploying Federated Authentication Services (FAS) in a multi-forest Active Directory that leverages selective authentication.
A common Active Directory deployment model includes leveraging multiple forests to segment components and provide additional security. This Active Directory forest segmentation is commonly based on the types of resources, computer objects and user accounts. This design is what Microsoft calls a resource forest model. One forest includes all the computer objects such as the Delivery Controllers, VDAs, FAS, and Certificate Authority while the other forest includes only user accounts. Different types of Active Directory trusts can be configured between the separate forests. When working with customers, we commonly see two-way Forest trusts configured with forest-wide authentication. This means bi-directional authentication is automatically established between all objects in the forests. However, some deployments may require a more restrictive authentication model between forests, where rights must be explicitly configured for every object. When this level of security is required, Selective Authentication is used to provide a “deny all, only allowed what is required” permissions model.
This article only covers the FAS configurations required. Other considerations must be taken into account when integrating other Citrix components such as the Delivery Controller or StoreFront in multi-domain environments. This is one of the more complex configurations, but it’s becoming more popular. Always remember, every Active Directory deployment is slightly different, so additional steps may be required to get your solution working. The configurations detailed below have been validated in both production and lab environments. For the OS, Windows Server 2016 was used for all infrastructure and Active Directory was at a 2012 functional level. The goal of this post is to provide the least-privilege configurations to enable FAS in this type of Active Directory deployment. We’ve covered most of the gotchas in this blog to help you get your FAS deployment up and running in no time.
Active Directory
Below are the required configurations that must be completed in each Active Directory forest. I’ve also included some of the common errors that you’ll see if the configuration is not implemented properly. I will be referencing the diagram below when referring to the location of items in Active Directory.
- Two-Way Trust Required. While one-way trusts would be ideal for security purposes, only two-way trusts are supported when deploying FAS in a multi-forest Active Directory. The reason is that the Certificate Authority servers from domain A must have the “Read” and “Allowed to Authenticate” permission on Domain Controllers in Domain B. If there was only a one-way outgoing trust from Domain A to Domain B to allow those users to authenticate, there wouldn’t be the trust in place to allow the computer objects in Domain A to have the required permissions in Domain B.
- Selective Authentication. To provide more fined grained security, rather than using the default “Forest-wide Authentication” setting, Selective Authentication requires permissions for user and computer accounts to be explicitly assigned in each forest. To allow the FAS deployment to function in this Active Directory configuration, “Read” and “Allowed to Authentication” permissions must be configured for certain items in the following locations:
- StoreFront and Federated Authentication Servers — All user accounts that will be used for authentication located in domain B must be configured with the required permissions on every StoreFront and FAS computer object. It is recommended to create a Domain Local Group in domain A that contains all the user accounts from domain B that will authenticate.
- Delivery Controllers — All user accounts that will be used for authentication located in domain B must be configured with the required permissions on every Delivery Controller computer object. It is recommended to create a Domain Local Group in domain A that contains all the user accounts from domain B that will authenticate.
- “Domain B” Domain Controllers — All certificate issuing servers, usually just the subordinate certificate authority (CA) servers not the Root CA, must be configured with “Read” and “Allowed to Authentication” permissions on every Domain Controller computer object in Domain B. It is recommended to create a Domain Local Group in domain B that contains all the CA computer objects from domain A.
- Additional Permissions for LTSR StoreFront — If you are using the Long Term Service Release (LTSR) version of StoreFront, you will also need to configure all StoreFront server computer objects with “Read” and “Allowed to Authentication” permissions on every Domain Controller computer object in Domain B. There is an underlying code difference with cross forest lookups that requires these permissions to be set. If you are using the Current Release 1906 (CR) version of StoreFront, these permissions are not required.
One of the items that has come to my attention is the confusion related to the multi-domain permissions detailed in this Citrix Knowledge Center article. This article recommends adding computer objects to the Windows Authorization Group on the users domain to allow for cross forest functionality. Configuring these permissions will not allow cross-forest authentication to work with Selective Authentication. Additionally, based on my testing, these permissions are also not required using separate forests with forest-wide authentication.
The information table shows the errors seen on Federated Authentication Services (FAS) and StoreFront when the permissions discussed above are not configured on the FAS server. If the users are not given the “Allowed to Auth” permissions on the StoreFront server specifically, you will get the “There was a failure with the mapped account” error when logging in via the website.
Federated Authentication Services
[S102] Server [RAL\XDC-001$] failed to assert UPN [roger2@users.local] (Exception: The computer you are signing into is protected by an authentication firewall. The specified account is not allowed to authenticate to the computer.
at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeAccessTokenHandle& safeTokenHandle)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
at Citrix.Authentication.UserCredentialServices.Server.ConvertCredentials.CreateCookieForCertificate(WindowsIdentity caller, String upn, SecurityIdentifier sid, RoleConfig roleConfig, String securityContext, Boolean wait))StoreFront
Failed to launch the resource ‘XDC1.Writeqqqq’ using the Citrix XML Service at address ‘??’. An unknown error occurred interacting with the Federated Authentication Service. See the inner exception for more details.
Citrix.DeliveryServices.FederatedAuthenticationService.VdaLogonDataProvider.Diagnostics.FasException, Citrix.DeliveryServices.FederatedAuthenticationService.VdaLogonDataProvider, Version=3.12.0.0, Culture=neutral, PublicKeyToken=null
An unknown error occurred interacting with the Federated Authentication Service. See the inner exception for more details.
System.ServiceModel.FaultException`1[[Citrix.Authentication.UserCredentialServices.FederatedAuthenticationServerFault, Citrix.Authentication.UserCredentialServices, Version=7.15.4000.0, Culture=neutral, PublicKeyToken=a80ce61cfbf8b47a]], System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Access Denied
- “Access this Computer From the Network” Permissions. Many organizations modify the “Access this computer from the network” settings from the default value of “Everyone” to a specific list of users and computers. For example, the setting is usually modified to remove Everyone and add Domain Admins to limit only administrators to RDP’ing to servers. In certain instances, this setting must be updated to include certain machines and users to allow a Citrix environment to function properly. In the case of Virtual Delivery Agent registration to the Delivery Controllers, it will be blocked if this setting is modified from the default and doesn’t include the computer objects for every Delivery Controller. When this setting is restricted in a FAS deployment, the following permissions are required:
- All User Accounts Authenticating — The user accounts for any user authenticating no matter if they are in the same forest or another must be allowed configure in this setting. It is recommended to assign groups to this setting, such as a Domain Local Group mentioned earlier that should include the user accounts from Domain B. This setting can be found at: “Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment”
Federated Authentication Services
Windows Event Logs:
"Logon failure: the user has not been granted the requested logon type at this computer."
You will see the following error in the Windows Event logs on the StoreFront Server and you will see the error below when authenticating to the StoreFront website.StoreFront
Windows Event Logs:
“An authentication attempt was made for user: roger2@users.local with realm context <unknown> that resulted in: Failed (Windows Error code: -1073741477)”
On the StoreFront website:
“There was a failure with the mapped account”
Certificates
Once the Active Directory configurations above have been complete, you should be able to successfully generate a user certificate and receive an ICA file to launch a virtual app or desktop resource. However, the next roadblock will be the trusts required to successfully authenticate to Windows. For that reason, the items below must be completed to enable users to authenticate.
- Cross Forest Certificate Issuing. To allow the Subordinate Certificate Authority servers in Domain A to issue certificate for users in Domain B, LDAP referrals must be enabled. To enable this setting, the following command must be run on all certificate issuing servers:
- Enable LDAP Referrals. certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
- Restart CA Service. net stop certsvc && net start certsvc
- Certificate Trust in the User Domain. To allow Domain B to successfully authenticate users with certificates generated from a CA in Domain A, the root and all intermediate certificates that are part of the chain of trust for the virtual smart card certificate must installed on the Domain B Domain Controllers. This can be accomplished by deploying the certificates in the correct stores using CERTUTIL or the Enterprise PKI snap-in. I recommend using the commands below, then using the Enterprise PKI snap-in to easily validate which certificates are present in these stores. When inside the “Enterprise PKI” MMC snap-in, right click and choose the Manage AD Containers menu. This snap-in is not installed by default and can be added using the following PowerShell command: “Add-WindowsFeature RSAT-ADCS-mgmt”.
- NTAuth Certificates — Import all Subordinate CA certificates. You do not have to import the Root CA certificates here.
certutil -dspublish -f c:\suboridate-ca1.cer NTAuthCA - A1A Container — Import the Root CA certificate. You do not have to import any Subordinate CA certificates here.
certutil -dspublish -f c:\root.cer SubCA - Certificate Authorities Container — Import the Root CA certificate. You do not have to import any Subordinate CA certificates here.
certutil -f -dspublish c:\root.cer RootCA - Update Settings — Run the following command to apply the settings after the certificates have been imported onto the user domain.
certutil -pulse
- NTAuth Certificates — Import all Subordinate CA certificates. You do not have to import the Root CA certificates here.
If the certificates from Domain A are not placed on the Domain Controllers for Domain B, which hosts the user accounts, the following errors will appear on each component:
On the Users Domain Controller:
The client certificate for the user USERS\roger is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.On the Virtual Delivery Agent:
Event Logs When Launching Desktop or App: The domain controller rejected the client certificate of user roger@users.local, used for smart card logon. The following error was returned from the certificate validation process: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
Message on the VDA: “the username or password is incorrect”
- Domain Controller Authorization Certificate on Domain B. A Domain Controller Authentication certificate must be present on the user’s domain (Domain B). The issue is further explained in this Citrix Knowledge Center article. To generate a Domain Controller Authentication certificate, you can use the certificate MMC to generate a certificate using the “Domain Controller template” . For additional guidance, see this Microsoft Technet article. When the certificate has been generated, run the following commands:
- Restart Key Distribution Center (KDC) — The KDC service must be restarted for the certificate import to take effect. Use the following command: net stop kdc && net start kdc
- You will see the following error when authenticating to your virtual resource if the domain certificate is not in place: “The request is not supported.”
- Also be sure that all of the VDAs and Domain Controllers on Domain A have the Root Certificate for Domain B. If not, certificate trust issues will occur.
Key Takeaways
After all of that, you should have the knowledge you need to deploy FAS in a multi-forest selective auth AD configuration! If you want first-hand experience integrating a solution like the one described in this article, contact Citrix Consulting for assistance. I’ll leave you with a quick recap of the key items I want to make sure you’ve learned from this post:
- Only two-way trust are supported. Whether you’re using forest-wide or selective authentication, there must be a two-way trust configured between the separate forests.
- Selective authentication requires permissions to be explicitly configured. To allow the solution to function, explicit permissions must be configured on each forest. Using Domain Local groups while nesting additional groups inside is recommended to easily configure permissions for multiple users located in separate groups.
- Certificates are required on the user Domain Controllers. The certificate chain that is part of the virtual smart card user certificate generated by FAS must be trusted on the Domain Controllers where the user objects are located.
- Restart the correct services, and beware of false negatives and positives! During my initial testing, I encountered many false negatives and positives, thinking that the configuration was or wasn’t working after the settings were configured. Many of the configurations detailed in this article require specific services to be restarted before they take effect. While restarting the entire server is always the more foolproof way, I’ve included the specific commands of services that need to be restarted.
- Lastly, be sure to check out the Troubleshooting FAS and Automating FAS blog posts by Citrix Consulting for additional FAS content.
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
