Desktop SSO is a feature that, by using Integrated Windows Authentication, allows devices joined to Active Directory (hereafter "AD") to automatically complete authentication to TrustLogin.

Note: An option application is required to use this feature. For pricing, see here.

▼ Introductory video for Desktop SSO

Setup Instructions

1. Configuration on the AD Server

Note: Steps 2 and 3 require command-line operations.

1. Create an AD user for Desktop SSO.
   Note: This user must belong to the [Domain Admins] group of the domain for which you are configuring Desktop SSO.
   Note: This user is used every time authentication occurs with this feature, so do not delete it.
   
2. Register the service principal name using the setspn command.
   Register: setspn -S HTTP/portal.trustlogin.com [AD user name created in Step 1]
   Note: Reference for the setspn command
   Remove: setspn -D http/portal.trustlogin.com [AD domain name]\[existing AD user name]
   Check: setspn -Q http/portal.trustlogin.com
   
3. Generate a keytab file using the following command.
   ktpass /out c:\[any KeyTab name].keytab /princ HTTP/portal.trustlogin.com@[AD domain name (uppercase)] /mapuser [AD user name created in Step 1]@[AD domain name (uppercase)] /pass [AD user password created in Step 1] /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1 /kvno 0
   Note: Due to AD specifications, the AD user's password will be changed to the password you enter above.
   　If the AD password policy prohibits reuse of previous passwords,
   　an error will occur.
   　In that case, specify a new password that complies with the policy and run the command again.

Save the generated keytab file locally.

2. Configuration in TrustLogin

1. Configure the user's sAMAccountName. Log in to the Admin Page, select the target member from "Admin Page > Members," open the "Custom Attributes" tab, and click "Edit." Configure the custom attribute for AD as follows and click "Save." (You can also register members in bulk via CSV.)

   ・ Attribute Name: 　UPN
   ・ Attribute Value:  [sAMAccountName]@[AD domain name (uppercase)]

   Note: If you use the AD Integration option, sAMAccountName is set automatically, so this step is not required. (AD Connectors downloaded before 2020/3/2 must be reinstalled.)
   Note: If you use SCIM IdP integration to obtain user attributes from Azure AD, this step is not required. However, AD and Azure AD must use the same domain.
   
   
   

2. Open the "Admin Page > Settings > Optional Features" menu, click the "Settings" button to the right of "Desktop SSO," and open "Add Desktop SSO Settings" on the screen that appears.
   
   

3. Fill in each field, upload the Keytab file, and click the "Register" button.
   "Select UPN" is used to specify the name of the custom attribute field that holds the UPN value required for Desktop SSO authentication.

   ・　Name: Desktop SSO login button name
   ・　Domain Name: AD domain name (uppercase)
   ・　Keytab File: Upload the Keytab file generated on AD
   ・ Select UPN: (Recommended setting) userPrincipalName for Azure AD SCIM users, UPN for all other users

   

4. Specify the users who will use Desktop SSO. Open the Desktop SSO settings screen and click the name of the Desktop SSO.
   
   
   Note: The service principal name is entered automatically.
   
5. Register the members who will use Desktop SSO via "Add Member."
   
   

3. Configuration on the User's PC

1. Configure integrated authentication settings in your browser.
   
   [Internet Explorer]
   ① Control Panel > Internet Options > Security > Local intranet > Sites
   Add "https://portal.trustlogin.com" to the zone.
   
   
   
   ② Control Panel > Internet Options > Advanced
   Make sure "Enable Integrated Windows Authentication" is checked.
   
   
   
   
   [Chrome, Edge (Chromium-based)]
   Note: Since these browsers share settings with Internet Explorer, please refer to the Internet Explorer configuration steps above.
   
   [Firefox]
   ① Enter about:config in the address bar and click "Accept the Risk and Continue."
   
   
   
   ② Search for [ network.automatic-ntlm-auth.trusted-uris ] and double-click the search result.
   Enter the string [ https://portal.trustlogin.com ] and click "OK."
   
   
   
   ③ Search for [ network.negotiate-auth.trusted-uris ] and double-click the search result.
   Enter the string [ https://portal.trustlogin.com ] and click "OK."
   
   
   
   ■ Firefox Configuration Tip
   To apply this setting in bulk using Active Directory group policy, please refer to the following article:
   Customizing Firefox Using Group Policy
   Note: This configuration is outside the scope of our support.
   
   

2. Verify that it works.
   
   On the TrustLogin login screen, enter the company ID and email address, then click the "Login" button.
   

   When connecting from a PC joined to an authenticated AD
   After clicking the login button, authentication is performed automatically, and upon success you are taken to My Page.

   

   When connecting from a device not joined to an authenticated AD
   On devices where Desktop SSO is not permitted, a "Log in with a different authentication method" button is displayed.
   Note: For users who have no authentication method other than Desktop SSO, clicking the button will not change the screen.

   
   

3. Select an authentication method other than Desktop SSO.
   Note: Clicking the Desktop SSO button returns you to the "Log in with a different authentication method" screen.

   
   

How to Prioritize Desktop SSO Authentication

1. Log in to the Admin Page, open the "Admin Page > Settings > Optional Features" menu, click the "Settings" button to the right of "Desktop SSO," and click the "Edit" button on the screen that appears.
   You can change this setting using the ON/OFF toggle to the right of "Prioritize Desktop SSO Authentication."
   
   ON: Desktop SSO authentication is attempted first; if it fails, the authentication method selection screen is displayed
   OFF: The authentication method selection screen is displayed from the start
   
   
   
   

Troubleshooting

Q1. I made a configuration mistake and am now unable to log in to TrustLogin.

A. Deleting the URL configured above disables Desktop SSO, allowing you to log in using another authentication method.

[IE, Chrome]

① Internet Explorer Tools > Internet Options > Security > Local intranet > Sites: Delete "https://portal.trustlogin.com".

[Firefox]

Delete the URLs that were configured in Firefox steps ①, ②, and ③ under "3. Configuration on the User's PC > 1. Configure integrated authentication settings in your browser" above.

Q2. Desktop SSO authentication fails.

A. If logging in with Desktop SSO fails, please check the following.

Q3. After updating to Windows 11 24H2, Desktop SSO stopped working.

A.

■ Cause of the Issue

Between the Windows AD server and the Windows PC:
・If the Kerberos encryption types are compatible, Desktop SSO can be used.
・If the encryption types are not compatible, Desktop SSO cannot be used.

On OS versions up to Windows 11 23H2, Desktop SSO worked without issue because these versions were compatible with the default encryption type (RC4) used by Windows Server 2016 and 2019 AD servers.

On Windows 11 24H2, however, RC4 encryption is disabled by default, which causes Kerberos authentication using RC4 (as used by Windows Server 2016 and 2019 AD servers) to be rejected. As a result, Desktop SSO no longer functions correctly on Windows 11 24H2.

You can review the change to this default value on Windows 11 in the following official Microsoft documentation.

https://learn.microsoft.com/ja-jp/windows/whats-new/deprecated-features

1. Summary of the Issue

Desktop SSO, which worked correctly on OS environments up to Windows 11 23H2, stopped working after updating to Windows 11 24H2.

2. Root Cause Analysis

■ Investigation Steps

Run the following command on the client device to check the details of the Kerberos ticket.

klist get http/portal.trustlogin.com

From the output of the above command, it was confirmed that the encryption type (Encryption Type) is RSADSI RC4-HMAC(NT), as shown below.

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Depending on the version of the Windows AD server, if the Kerberos encryption type is not explicitly configured, the OS default value is used automatically.

3. Solution

■ Approach

Change the encryption method used for the Kerberos ticket used to communicate with the TrustLogin server on the AD server to a method that is compatible with Windows 11 version 24H2 and later.

■ Steps

3.1　If you have previously changed the Windows security policy "Network security: Configure encryption types allowed for Kerberos" via group policy or local security policy, applying the setting in 3.2 may cause Desktop SSO to stop working on existing Windows devices.

Before performing this work, be sure to confirm that the Kerberos encryption types allowed on all Windows devices using Desktop SSO are not restricted to "RC4" only.
Note: See "4. Additional Notes " at the end for how to check this.

3.2　Configuration Changes in Active Directory (AD)

Check the AD user account configured for Desktop SSO.
(This is the AD user account configured using setspn on the AD server.
　It refers to the AD user created in "1. Configuration on the AD Server, step 1" of the setup manual)　

https://support.trustlogin.com/hc/ja/articles/360000548741

Apply the following settings to the relevant AD user.

• Open the Properties screen for the relevant user, enable the "This account supports Kerberos AES 256 bit encryption" checkbox under "Account Options," and click "OK" or "Apply."

The encryption type for communication with the TrustLogin server is now AES 256.

Note: The only change needed overall is the one described above. No configuration changes are required for individual AD users.

3.3　Updating Group Policy on the Client PC

Run the following command to apply the changes made on AD to the client.

gpupdate /force

3.4　Rechecking the Kerberos Ticket

Run the following command again to check the encryption method used when the ticket is obtained.

klist get http/portal.trustlogin.com

If the output displays the following, the configuration is correct:

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

3.5　Verifying Desktop SSO Operation

On the target client device, verify that authentication via Desktop SSO works correctly.

4. Additional Notes
Be sure to confirm that the Kerberos encryption types allowed on Windows devices using Desktop SSO are not restricted to "RC4" only.

4.1　Items to Check in Local Policy

As an administrator, check [Local Group Policy Editor]>[Security Settings]>[Local Policies]>[Security Options]>[Network security: Configure encryption types allowed for Kerberos]> security setting.
If nothing is checked, select the items as shown below.

Also make sure the following items are selected.

RC4_HMAC_MD5, AES128_HMAC_SHA1, AES256_HMAC_SHA1

Future encryption types

4.2　Checking the Registry Value

Please check the value of the following item in the registry.

Path:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

Value to Check:
If the value of SupportedEncryptionTypes is 0x7ffffffc (hexadecimal), the setting is correct.

If it is a different value, update it to 7ffffffc.

Q4 ）Desktop SSO authentication fails after applying the Windows Update released in April 2026

A）
■ Affected Customers
Customers using Desktop SSO whose AD server (Active Directory) has one of the following Windows Updates applied
Note: Users who only use AD integration are not affected.

KB5082123: For Windows Server 2019
KB5082142: For Windows Server 2022

■ Cause

The above update (addressing CVE-2026-20833) changed the encryption method behavior in the Kerberos KDC (Key Distribution Center).

Details of the Behavior Change
Before the change: msds-SupportedEncryptionTypes — if not set, the domain default (including RC4) was used
After the change: msds-SupportedEncryptionTypes — even if not set, only AES-SHA1 is now prioritized
Reference: How to Manage RC4 Kerberos KDC Usage for Changes to Service Account Ticket Issuance Related to CVE-2026-20833 - Microsoft Support

As a result, if the keytab exported using the ktpass /crypto All option described on the support page contained an RC4 key, this creates a mismatch in the encryption method with the KDC, resulting in authentication failure.

■ Remediation StepsPlease perform the following on the AD server.

Note: Prerequisites
The AD account used to perform this work must belong to the Domain Admins group. If permissions are insufficient, SPN registration or keytab generation will fail. Please check this in advance.

1. Delete the existing SPN
   After checking the existing registration status, delete the target SPN using the setspn -D command.
2. Re-register the SPN
   setspn -S Use this command to re-register it. After registering, confirm that there are no duplicates.
3. Regenerate the keytab file
   ktpass Run this command.
   Please note the following points.
   
   Notes
   ・Specify an encryption strength of /crypto AES256-SHA1 or higher (the /crypto All option that was listed on the support page before May 8, 2026 is not recommended because it includes RC4)
   ・/kvno 0 option must always be specified. Omitting it may cause authentication to fail due to a kvno mismatch
4. Re-upload the keytab file to TrustLogin
   Upload the generated file from the Desktop SSO settings screen in the admin console.