Configure WinSSO realm to use custom SPN

    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected:  [All Versions]


    How to configure WinSSO realm to use custom SPN to use Kerberos instead of NTLM? 


    AD side settings
    SPNs need to be assigned to the username that will be used for IIS Application pool(s).
    1. Create the user account in Active Directory that will be used as service account for the IIS application pool
    2. Assign HTTP Service Principal Names (SPN) to the service account

    • Setspn -s HTTP/ Your_ServiceAcct_Name

    To rollback the change, if required:

    • Setspn -D HTTP/ Your_ServiceAcct_Name

    Client-side Kerberos logging
    Enable Kerberos event logging on the client computer to test Kerberos authentication. This will log detailed Kerberos events to troubleshoot Kerberos.

    1. Start Registry Editor.
    2. Add the following registry value:
      Registry Value: LogLevel
      Value Type: REG_DWORD
      Value Data: 0x1
      If the Parameters subkey does not exist, create it.
    3. Quit Registry Editor. The setting will become effective immediately on Windows Server 2012 R2, Windows 7, and later versions.

    Note: Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer.
    IDP side settings
    Add the newly created account into the local administrators group on IDP servers. On SecureAuth side some of the local GPO policy settings need to be set for the created service account.
    1. If you want to push the below policies via your Active Directory GPO, use GPMC.msc on your Domain Controller and create/update the GPO that gets applied to the IDP servers. Otherwise, open Local Group Policy Object Editor (gpedit.msc) on the IDP servers.
    Note: If there are conflicting settings between Domain and Local group policies, the domain GPO takes precedence.
    2. Click Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
    3. Add the username to these Local Policy settings (for example, domain\Your_ServiceAcct_Name) in any of the following ways:

    • Log on as a batch job.
    • Log on as a service.
    • Replace a process level token.
    • Adjust memory quotes for a process.

    Open IIS Manager and do the following:

    a. Click Application Pools.
    b. Select the pool that will use the custom identity’s SPN for Kerberos authentication.
    c. Click Advanced Settings.
    d. Under Process Model, click the Identity section, and then select the Custom Account option.
    e. Enter the useraccountname (i.e. domain\Your_ServiceAcct_Name) and password.
    f. Click OK.
    Realm Configuration
    Sign-in to the SecureAuth0 realm - https://localhost/SecureAuth0/localadmin.aspx

    1. Click on your Windows SSO realm in the left pane.
    2. Go to the workflow tab > custom identity consumer section > Set below fields to True:
      • Windows Authentication
      • Use Kernel Mode
      • Use AppPool Credentials    
    3. Hit Save.
    4. For the above changes to take immediate effect:
      • Set Windows Authentication to false > hit save
      • Set Windows Authentication back to true > hit save
      • At this point, Windows Authentication, Use Kernel Mode, and Use AppPool Credentials options must be set to True.
    5. Navigate to any other realm and then navigate back to the above settings in SecureAuth6 realm to make sure all the below fields are set to true:
      • Windows Authentication
      • Use Kernel Mode
      • Use AppPool Credentials

    To rollback the change, if required:

    • Set Windows Authentication, Use Kernel Mode, and Use AppPool Credentials fields to false and then set Windows Authentication back to true.

    Additional information:  


    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.

    0 out of 0 found this helpful



    Please sign in to leave a comment.