How To: Configure a WinSSO Realm to Use a Custom SPN

Version Affected: All

 

Overview

This article explains how to configure a Windows SSO (WinSSO) realm to use a custom Service Principal Name (SPN), so that Integrated Windows Authentication (IWA) uses Kerberos instead of falling back to NTLM. This requires an existing Windows SSO realm, and a service account that will run the realm's IIS Application Pool.

Configure the Service Account and SPN in Active Directory

1. Create a user account in Active Directory to use as the service account for the realm's IIS Application Pool.
2. Assign an HTTP SPN to the service account:

Setspn -s HTTP/my.example.com Your_ServiceAcct_Name

See Microsoft's SPN Configurations for Kerberos Authentication for more background on SPNs.

To roll back this change, if required:

Setspn -D HTTP/my.example.com Your_ServiceAcct_Name

Grant Local User Rights to the Service Account

The service account also needs the following local user rights on the IdP server(s), which can be applied via Group Policy or the Local Security Policy:

• Log on as a batch job
• Log on as a service
• Replace a process level token
• Adjust memory quotas for a process
• Impersonate a client after authentication

1. If you want to push these policies via your Active Directory Group Policy Object (GPO), use GPMC.msc on your Domain Controller and create or update the GPO that applies to the IdP servers. Otherwise, open the Local Group Policy Object Editor (gpedit.msc) directly on the IdP servers. If there are conflicting settings between Domain and Local group policies, the domain GPO takes precedence.
2. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
3. Add the service account (for example, domain\Your_ServiceAcct_Name) to each of the 5 user rights listed above.

Set the Application Pool Identity in IIS

1. Open IIS Manager and click Application Pools.
2. Select the pool that will use the custom identity's SPN for Kerberos authentication.
3. Click Advanced Settings.
4. Under Process Model, click the Identity section, then select the Custom Account option.
5. Enter the service account (for example, domain\Your_ServiceAcct_Name) and its password.
6. Click OK.

Configure the Realm

Sign in to the SecureAuth0 realm's Admin Console (for example, https://localhost/SecureAuth0/localadmin.aspx).

1. Click your Windows SSO realm in the left pane.
2. Go to the Workflow tab, and in the Custom Identity Consumer section, set the following fields:
   • Receive Token -- Token
   • Require Begin Site -- True
   • Begin Site -- Windows SSO
   • User Impersonation -- True
   • Windows Authentication -- True
   • Use Kernel Mode -- True
   • Use AppPool Credentials -- True
3. Click Save.
4. For these changes to take effect immediately, rather than waiting for the next recycle:
   • Set Windows Authentication to False and save.
   • Set Windows Authentication back to True and save.
5. Navigate to any other realm, then navigate back to this realm's settings and confirm that Windows Authentication, Use Kernel Mode, and Use AppPool Credentials are all still set to True.

See SecureAuth's Configure a Custom Identity's SPN to Leverage IWA Auth and What's New: Custom Identity Consumer Section pages for more background on these fields.

To roll back this change, if required, set Windows Authentication, Use Kernel Mode, and Use AppPool Credentials to False, then set Windows Authentication back to True.

Special Considerations

To confirm whether a login is actually using Kerberos, rather than IIS silently falling back to NTLM, see How To: Enable Additional Kerberos Logging to Diagnose SPN Issues, which also covers enabling Kerberos event logging on the client computer. For general browser configuration needed for Windows SSO, see SecureAuth's Browser Settings for Windows SSO guide. If the service account is missing the Impersonate a client after authentication right, IIS raises Either a required impersonation level was not provided, or the provided impersonation level is invalid. (Exception from HRESULT: 0x80070542) when a client tries to authenticate -- grant the right above to resolve it.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.