Sep 26th, 13
More fun today with Kerberos and load balancers. Today’s challenge related to getting the Microsoft App-V publishing server to work with an F5 load balancer in a Layer 4/n-Path/DSR configuration. Everything was working when I was accessing the individual server nodes, but when I switched to using the load balanced name and address, authentication started to fail.
After lots of log searching I eventually tried a wire trace, and found the following Kerberos error in the response from the App-V server to the App-V client:
Lots of different resources helped here:
- This TechNet page explains various Kerberos errors and why they might occur:
Of note is the scenario where the account handling the authentication request does not hold the SPN for which the request was made. I set the SPN for my IIS application pool identity, but further analysis of the error packet shows that it was handled by my App-V server machine account, not the service account. Augh! Why?
- This thread on TechNet Social was the biggest help:
The user posted all of the steps they followed in configuring IIS and the service account SPN, including the tidbit:
changed the authentication of the “Management Service” web site to useAppPoolCredentials=”true”
I have never used this particular setting, so I dug into it…
- The following MSDN article explains the IIS 7.0 feature of “kernel authentication”, how it affects the need for SPN entries, and its interplay with application pool identity accounts:
Basically, with kernel-mode authentication, the SYSTEM account will handle all Kerberos authentication by default. This explains why we were seeing Kerberos errors in the communications with the App-V client… the IIS pool identity account was not handling Kerberos delegation!
Of special interest is this statement:
Disable Kernel mode authentication and follow the general steps for Kerberos as in the previous IIS 6.0 version.
[Recommended for Performance reasons]
Let Kernel mode authentication be enabled and the Application pool’s identity be used for Kerberos ticket decryption. The only thing you need to do here is:
1. Run the Application pool under a common custom domain account.
2. Add this attribute “useAppPoolCredentials” in the ApplicationHost.config file.
- This TechNet page documents how to configure Kerberos auth in IIS, and mentions the use of the IIS appcmd.exe to set the “useAppPoolCredentials” option:
Included is the exact command line required to set the value to true:
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true
(But the page does not really tell you what it is for, which is where the MSDN article comes in handy.)
So, Kerberos under IIS 7 and later has some nuances not present in IIS 6. I wonder how I did not encounter this before?
Jun 30th, 09
Previously I documented a rough outline of the AX 5.30 Infrastructure installation process:
With support for 5.30 expiring today, I think it high time we got our infrastructure up to date up to the most current version that is supported for use with SunGard Banner.
- Uninstall all previously existing AX components. Purge any residual files from the IIS publishing directories, “Program Files”, “Application Data”, and the registry.
- Set security for the global impersonation account according to the table on page 210 of the “concepts and planning guide”.
- Note that the account does not have to be a local administrator!
- However, the security accounts will have to have privileges to the resources accessed by the services (i.e. NTFS filesystems rights, shared folder access).
- Rendering Service –
- When granting rights to the DX data store, plan ahead. Permissions could take a long time to apply.
- Requires Local Security Policy “Replace a Process Level Token” and “Adjust memory quotas for a process” rights. Also, the “Allow service to interact with the desktop” box must be deselected in the “Log On” tab of the Rendering service properties.
- WebAccess.NET Services –
- Global Account needs only “Log on as a service” Local Security Policy assignment. You can clear out all “legacy” security permissions as they are not needed for WebAccess!
- Install AX Desktop, installing all administration tools:
- msiexec /i “ApplicationXtender Desktop.msi” /qb ADDLOCAL=DocumentManager,AppGen,ConfigurationTools,ManagementTools
- Install the new License Server and install license file:
- Install the “ApplicationXtender License Server.msi” (FlexNet License Manager)
- Drop the .LIC license file into C:\Program Files\XtenderSolutions\Content Management\License Server
- Configure the Login identity of the “ApplicationXtender License Client Components” COM+ application to use the global impersonation account. This component must be shut down to be reconfigured. Details in EMC PowerLink solution esg92864.
- Restart the “ApplicationXtender License Service” Service.
- Install the “EMC License Server” (Proprietary License Server, to support DiskXtender)
- Install all current patches to the service
- Run the “License Server Administrator” GUI.
- Go to “Tools”, then “New License Wizard” to install the DiskXtender License.
- Install DiskXtender
- Install DiskXtender patches, in sequence
- When prompted for the DX service account, you must provide an account that has local “administrator” rights, and the ability to “log on as a service”.
- Verify and/or re-establish RPC partition maps – See the “Core Components” guide for instructions.
- Consider switching to DCOM security model, which will require modifying the “AE_PATHS” table in each data source db. See page 160 of the “Desktop Install Guide” for details.
- This is not actually practical to do since it will break AX Desktop on any system that is not joined to the CAMPUS domain (and why would they not be joined, I wonder?)
- Launch AX Admin
- See “ApplicationXtender Desktop Installation Guide” for details
- Log in as SYSOP and perform the database upgrade, if prompted.
- Verify global settings:
- Add license server configuration: see “Core Components” guide for details.
- Web Access .NET must use Global credentials since we are using and Oracle database with Oracle security.
- Save the configuration and exit
- Launch AppGen, and verify functionality.
- Connect to each defined data source, one at a time.
- Perform database upgrades if prompted (this should be safe, but can take several minutes to complete).
- Set IIS web site root to use ASP.NET 2.0.
- Install AX Web Services, making sure to install the required “Utility Services” component. “AX Web Services” and “Workflow” components are optional.
- See “AppXtender Core Components Admin Guide” for installation and config details.
- Choose IIS installation option, and install into “Default Web Site” (which should be the only site present)
- Ensure that “Default.aspx” is listed as an accepted default page for the “AppXtender” IIS web application.
- Install AX Web Access .NET
- Install AX Rending Server
- Run the Component Setup Wizard for all installed components
- Outside of my control:
- BannerXtender updates need to be applied to production Banner systems.
- DocSend and ECopy stations need to be upgraded to 5.40 AX Desktop releases
- DocAccel server needs 5.40 AX Desktop upgrade
- All AX desktop clients need updates, too.
- Anyone using WX WebAccess.NET ActiveX controls will need to upgrade these components.
- Test Test Test!
Feb 13th, 09
So, you have a site that needs to to run over SSL-only (shouldn’t they all?)? You don’t trust your clients to type that ever-important “s” after “http” (and why would they?)? You think they will get scared off by those “Secure connection required” error pages (they will!)? You are not running IIS7 (who is?)? Not using ASP.NET?
Codplex to the rescue! The venerable “Ionic URL Rewrite” ISAPI filter has been updated, and published on Codeplex:
IIRF now supports the ability to return URL redirects, in addition to simple rewrites. To use IIRF to redirect a non-SSL URL to a secure version, follow the installation instructions included with IIRF. Then:
- Stop your production IIS site from listening on port 80 and enforce SSL usage.
- Make sure that the production site is not using host headers that would override your port settings.
- Set up a secondary IIS site which listens on port 80 only. Add the IIRF ISAPI filter to this site.
Here is some sample entires you could use in the IsapiRewrite4.ini configration file to accomplish the redirect. Note that [R] instead of [R=301] also works, but this performs a 302 “Temporary” redirect. Conceptually I prefer a 301 (not that it matters because search crawlers are not hitting our Intranet sites):