Intro and context

Many organisations use Kerberos workflows based on Microsoft Active Directory for handling SSO for browser-based (HTTP, HTTPS) applications.

These Kerberos workflows require various configuration activities like setting up the Kerberos server, configuring systems that should be able to accept Kerberos token requests to logon, and so on… this blog assumes that on the server-side everything is configured correctly, so that e.g. Kerberos is known to be already working, or has previously been working. Our scope will be advice on configuring the client-side computers and their browsers; for example, in case some OS+Browser combination isn’t already working, you might find the blog’s advice useful.

We give solutions for three OS-paradigms: for Windows 11; for Apple macOS (i.e. MacBooks); and for Xubuntu Desktop (Linux).  Scroll down to the OS you are interested in.

Then there are two Appendices – Appendix A: Other browser properties gives some info about two other browser properties that may need to be configured (they weren’t relevant for my environment, therefore not implemented by me); Appendix B: SAP Secure Login Client shows how to manually get the Kerberos token for SAP Secure Login Client (on Windows) .

Disclaimer: Think of this blog as “Tips and Tricks” on client side of Kerberos config. Really, I cannot provide debug help to any readers – instead, just wishing yous all good luck fixing your own specific cases and configurations using your own debug-n-configure skills! 👍

 

Windows 11 – general remarks

An indication that the client-side config needs improving can be that when you try to logon to some website on your intranet, you are prompted in Edge or Chrome to first supply your AD logon credentials manually, e.g.:

In Firefox, you might be directed instead straight to the manual logon page of the website itself.

So we want to fix these situations, by configuration. The Edge and Chrome browsers have similar configuration steps, as they are both based on Chromium. Firefox has a different way to handle Kerberos config.

 

Windows Settings app (Edge, Chrome)

Open Settings app, go to Network & internet -> Advanced network settings -> Internet options … the Internet Properties dialog should open, go to Security tab and select Local intranet:

From there, click on Sites -> Advanced, then add the websites of interest… there are 2 ways you could do this addition – first way is to specify each website (protocol + hostname), for example:

http://nw-portal.example.com

https://sap-solman.example.com

…and so on, accumulating items as you discover the websites where AD-based SSO should work.

Another way is to use generalise using wildcards, and also we can generalise by not specifying a protocol – i.e. we cover both the HTTP and the HTTPS cases, and can get away with a one-line addition… e.g. if all our relevant websites are subdomains of example.com then:

*.example.com

[Note that if your main domain, example.com for uhh, example… if it also offers authentication of SSO requests, then you would likely add “example.com” as an extra item, since it isn’t covered by “*.example.com” due to the dot after the wildcard].

Anyway then we can close the windows (Close -> OK) to get back to Internet Properties window, and then for Security->Local intranet, we click on Custom level… scroll down to User Authentication and make sure Logon radiobutton “Automatic logon only in Intranet zone” is on. Then OK to close the window. Then switch to Advanced tab and scroll down to Security section and make sure “Enable Integrated Windows Authentication” is on. Then OK to close the Internet Properties.

If you close then reopen Edge and Chrome, they will now be able to use the computer’s Kerberos TGT (ticket granting ticket) to authenticate to the named server/protocol combinations.

It might be that the option to Add websites in the Local intranet -> Sites dialog box, is greyed out with a message saying that this setting is managed by your organisation’s System Administrators. If so, you could ask your admins to rollout a policy that includes the needed websites; or you can check out the other solutions in this blog.

 

Windows HKLM Registry approach (Edge, Chrome)

For this approach, you need to have local administrator rights to your computer. Two ways to make the changes are now described, before that though: close Edge and Chrome completely (check and take action in Task Manager if needed).

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authserverallowlist

The first way, is to open a Command Prompt in Run as Administrator mode, then run the following two commands, replacing “*.example.com,example.com” with the list relevant to your own organisation – you can specify actual servers and/or use wildcards:

reg add HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftEdge /v AuthServerAllowlist /t REG_SZ /d *example.com,example.com /reg:64 /f

reg add HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome /v AuthServerAllowlist /t REG_SZ /d *example.com,example.com /reg:64 /f

Then restart Edge and Chrome, and check the policy has been picked up by entering the relevant URL for each browser:

edge://policy

or

chrome://policy

 

Now you should be able to logon to the websites that use AD-based Kerberos for SSO logon (assuming of course that the Kerberos configurations on the server-side are correct).

The other way to do this config, is to open the app called ‘regedit’ (Registry Editor) and from there implement the same stuff as specified in the commands given above or relying on the Microsoft advice in the link above. Leaving that as an exercise for the reader.

See Appendix A: Other browser properties for other properties of Edge and Chrome that may also be relevant to configure.

 

Windows – and MacBook – using Firefox

If you do not have the rights to implement solutions for Edge and Chrome, or if you just prefer using Mozilla Firefox, then this solution might be useful…

Open Firefox and enter the URL:

about:config

Click past the warning message. Search for the key:

network.negotiate-auth.trusted-uris

Enter some relevant value – you can enter a comma-separated list, or a generic wildcard value (no asterisk needed though), for example:

nw-portal.example.com,sap-solman.example.com

or:

example.com

Hit <Enter> to save your changes. And that is all that should be needed. Now you can SSO into those websites that are accepting AD-based Kerberos logons.

[Be aware that to SSO into a second website using a different authentication server, probably you will need to create a new Firefox session e.g. a guest session, so that Firefox doesn’t offer the second server an (invalid, in the second server’s opinion) token from the first server].

See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity.

 

MacBook using Firefox

The configuration steps are exactly the same as for Firefox on Windows, so refer to previous section above “Windows – and MacBook – using Firefox”.

By implementing this solution, you would typically be replacing the original authentication failure (HTTP 401 Unauthorised, returned because the website received no AD-based Kerberos credentials), as a result of which the website falls back to asking for manual logon:

…so yeh, we’re replacing that HTTP 401 with successful SSO logons to the website using AD-based Kerberos, thanks to our minor config change.

See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity.

 

MacBook using Safari

So far, this combination has always worked out of the box for me in various work environments, so I don’t have any advice on how to configure Safari for AD-based Kerberos logins, as never had any need to investigate that. Anyway it seems that Safari relies on Apple’s Kerberos SSO Extension implementation:

https://support.apple.com/en-gb/guide/deployment/depe6a1cda64/web

FYR: on MacBook you can view your AD-logon details using the app called “Ticket Viewer”, or in Terminal you can run the commands:

klist

klist -v

…to see information e.g. about e.g. the krbtgt (Kerberos Ticket Granting Ticket).

 

MacBook using Chrome and Edge

The solution is quite easy (though like most things that look easy, finding the solution wasn’t that easy).

Close Chrome and Edge. Open the Terminal app, and run the following commands, replacing “*.example.com,example.com” with the relevant list of servers and/or wildcard entries that fit your own organisation’s needs best:

defaults write com.google.Chrome AuthServerAllowlist “*.example.com,example.com“

defaults write com.microsoft.Edge AuthServerAllowlist “*.example.com,example.com”

These commands add an entry to the respective plist files:

~/Library/Preferences/com.google.Chrome.plist 

~/Library/Preferences/com.microsoft.Edge.plist

(Xcode is the best app for viewing those plist files).

Anyway now you can re-open Chrome and Edge, and if you like you can check that the relevant policy was uploaded by the browser using the relevant URL:

chrome://policy

edge://policy

Now your AD-based Kerberos SSO into relevant websites should work fine. See (below) Appendix A: Other browser properties in case similar work needs to be done for those other properties.

[You can use Guest sessions, or switching between Chrome personas, if you want to access multiple different websites while avoiding the trap where the first website’s tokens are offered to the second website for that second website to reject them :)].

 

Xubuntu and Kerberos

Xubuntu Desktop distro is a popular variant of Ubuntu Desktop (difference is only in the Desktop Manager – actually I obtained the Xubuntu Desktop by installing arm64 Ubuntu Server, and then installing the Xubuntu packages).

First we need to set up the client machine’s Kerberos functionality:

https://documentation.ubuntu.com/server/how-to/kerberos/basic-workstation-authentication/

sudo apt install krb5-user sssd-krb5

We give the “realm” (which in my case is the hostname of the Kerberos server), and hit <Enter>

For us, it is enough to be able to obtain a Kerberos ticket “on demand”, so we skip the sssd-configuration and instead just test the ‘kinit’ utility:

kinit <ADUSER>@<Kerberos.server>

Then check if the krbtgt (Kerberos Ticket Granting Ticket) was obtained:

klist

We probably also need to specify explicitly, in the main Kerberos config file, where the Ticket cache is (filepath and syntax visible via ‘klist’ in above screenshot)… so let’s do that:

sudo nano /etc/krb5.conf

Add the relevant value, here is an example:

default_ccache_name = FILE:/tmp/krb5cc_1000

Ctrl+O, Ctrl+X to save and exit from the editor.

 

Xubuntu Chromium

We can use the advice from this Ask Ubuntu thread:

https://askubuntu.com/questions/1204571/how-to-install-chromium-without-snap

sudo add-apt-repository ppa:xtradeb/apps -y

sudo apt update

sudo apt install chromium

[Yes that is Chromium, not Chrome… as of September 2025 when doing these POCs, no arm64 Chrome for Ubuntu-family desktop distros available… so we take Chromium, which is the upstream browser project from which Chrome (and Edge) are derived].

If like me you are running this Linux distro as a VM that is not pre-configured by your organisation, then you may want to export your organisation’s CA and Root CA .pem files (e.g. in the host machine, go to some intranet website and export the certificates from there), and then import them into your Linux Chromium browser, from here:

chrome://certificate-manager/localcerts

Result of your imports should show up in “Installed by you” section of the settings…

[For non-GUI-browser situations, e.g. when using curl or wget, there is a different solution for importing the certificates to the Ubuntu filesystem, but that is outside the scope of this blog].

Anyway we can then start up Chromium from the command line supplying the temporary list of Authenticating-by-Kerberos servers, as a comma-separated list and with relevant wildcard use according to your needs:

chromium –auth-server-allowlist=”*.example.com,example.com”

So this should work (try Refresh in case the first time the browser uses some previously cached “manual login” page). But it would be better to implement a solution that doesn’t require the user to specify options from the command line each time they open Chromium, so here is the more permanent solution… I used these pages of advice, note that there are Ubuntu-specific and Chromium-specific paths involved…

https://support.google.com/chrome/a/answer/9027408?hl=en

https://www.chromium.org/administrators/linux-quick-start/

For this example we will use the managed_policies.json file i.e. make the new policy mandatory for users…

sudo mkdir -p /etc/chromium/policies/managed

cd /etc/chromium/policies/managed

sudo touch managed_policies.json

sudo pico managed_policies.json

Add the policy:

{

    “AuthServerAllowlist”: “*.example.com,example.com”

}

Ctrl-O, Ctrl-X to save and exit from the pico-editor.

Now we can start Chromium up e.g. from the GUI Menu, under category Internet, and check that the new policy was loaded by going to

chrome://policy

 

Now our SSO via AD-based Kerberos works fine. Note that to switch from one SSO over AD-Kerberos workflow to one provided by another server, you may need to close Chromium then re-open it.

See Appendix A: Other browser properties for other properties of Chromium that may also be relevant to configure. 

 

Xubuntu Firefox… the right kind of Firefox

Recent editions (e.g. 24.04 LTS) of Ubuntu Desktop are delivered with the so-called “snap”-package variant of Firefox already installed; however I found that this “snap”-Firefox doesn’t work with Kerberos, not for me anyway. So instead, we should get rid of “snap”-Firefox and replace it with “apt-repo”-Firefox. Here is the advice I used:

https://askubuntu.com/questions/1399383/how-to-install-firefox-as-a-traditional-deb-package-without-snap-in-ubuntu-22

“[…]

sudo add-apt-repository ppa:mozillateam/ppa

Then, copy and paste the following code in a terminal in one go (don’t copy-paste line by line) to prioritize the apt version of firefox over the snap version.

echo ‘
Package: *
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001

Package: firefox
Pin: version 1:1snap*
Pin-Priority: -1
‘ | sudo tee /etc/apt/preferences.d/mozilla-firefox

Next, remove the snap version of firefox

sudo snap remove firefox

[…]

Install Firefox with apt.

sudo apt install firefox

[…]”

Ok good – note that now we cannot open Firefox as default Web Browser directly from top-level GUI menu (as “Web Browser” refers to deleted snap-version); instead we can use the GUI category “Internet” (Chromium is also listed under this category) and open our new Firefox item there… or type “fire” in the menu search bar and choose Firefox… or we can start the new Firefox from command line:

firefox

Then we should import any needed CA certificates of the organisation…  from the “I-ching” icon in top-right of Firefox menu bars, choose Settings, then type “cert” so that “View Certificates” option comes up:

Open the View Certificates dialog and choose Import.. and then, well, import the needed certificates. Once done, those are visible in View Certificates (scroll through list till you see them).

Now we are at the stage where we can do the same procedure as with Firefox on other OSes above…enter the URL:

about:config

Click past the warning message. Search for the key:

network.negotiate-auth.trusted-uris

Enter some relevant value – you can enter a comma-separated list, or a generic wildcard value (no asterisk needed though), for example:

nw-portal.example.com,sap-solman.example.com

or:

example.com

Hit <Enter> to save your changes. And that is all that should be needed. Now you can SSO into those websites that are accepting AD-based Kerberos logons.

 

 See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity.

 

Appendix A: Other browser properties

FYR: in case your Kerberos setup involves credential-delegation servers, and/or in case you need to specify an Authentication Scheme in e.g. Edge (cases I have no actual experience with) then the following Keys and their values may be of interest:

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authnegotiatedelegateallowlist

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authschemes

[These links are about Edge, but in practice Edge, Chrome, and Chromium are a family – Edge and Chrome based on Chromium – so there are many properties that are identical by name and function].

Chrome, Edge:

AuthNegotiateDelegateAllowlist

AuthSchemes

Firefox equivalent of AuthNegotiateDelegateAllowlist (via about:config we can modify this key):

network.negotiate-auth.delegation-uris

… The AuthNegotiateDelegateAllowlist Keys (and Firefox equivalent) would have as value typically some hostname such as:

authserver.example.com

If your organisation is using other paradigms for authentication such as NTLM, then you might need or want to specify the AuthSchemes Key with the relevant schemes as values in comma-separated form, for example with Kerberos and NTLM you would have:

negotiate,ntlm

 

Appendix B: SAP Secure Login Client

Although this blog is focused on browsers, we note that SAP Secure Login Client can also use AD-based Kerberos tokens for SAPGUI SSO. Normally, the Secure Login Client obtains the needed Kerberos token from the user’s cache… however, we had a situation during initial testing of Windows 11, where for some reason this automatic retrieval of Kerberos token was not working for a while. So, in such cases, here is a possible (though not very elegant or scalable) workaround…

In the Windows In-Tray -> click on the wee icon with a white tick-mark on a blue diamond background (SAP Secure Login Client):

Double-click on the relevant item that says “Kerberos Token”:

Enter your AD-credentials and click “OK”:

Assuming the AD logon succeeds, now your AD-based Kerberos SSO logons to SAP systems via SAPGUI sessions should work again, as SAP Secure Login Client has the Kerberos token it needs.

 

 

​ Intro and contextMany organisations use Kerberos workflows based on Microsoft Active Directory for handling SSO for browser-based (HTTP, HTTPS) applications.These Kerberos workflows require various configuration activities like setting up the Kerberos server, configuring systems that should be able to accept Kerberos token requests to logon, and so on… this blog assumes that on the server-side everything is configured correctly, so that e.g. Kerberos is known to be already working, or has previously been working. Our scope will be advice on configuring the client-side computers and their browsers; for example, in case some OS+Browser combination isn’t already working, you might find the blog’s advice useful.We give solutions for three OS-paradigms: for Windows 11; for Apple macOS (i.e. MacBooks); and for Xubuntu Desktop (Linux).  Scroll down to the OS you are interested in. Then there are two Appendices – Appendix A: Other browser properties gives some info about two other browser properties that may need to be configured (they weren’t relevant for my environment, therefore not implemented by me); Appendix B: SAP Secure Login Client shows how to manually get the Kerberos token for SAP Secure Login Client (on Windows) .Disclaimer: Think of this blog as “Tips and Tricks” on client side of Kerberos config. Really, I cannot provide debug help to any readers – instead, just wishing yous all good luck fixing your own specific cases and configurations using your own debug-n-configure skills! 👍 Windows 11 – general remarksAn indication that the client-side config needs improving can be that when you try to logon to some website on your intranet, you are prompted in Edge or Chrome to first supply your AD logon credentials manually, e.g.:In Firefox, you might be directed instead straight to the manual logon page of the website itself.So we want to fix these situations, by configuration. The Edge and Chrome browsers have similar configuration steps, as they are both based on Chromium. Firefox has a different way to handle Kerberos config. Windows Settings app (Edge, Chrome)Open Settings app, go to Network & internet -> Advanced network settings -> Internet options … the Internet Properties dialog should open, go to Security tab and select Local intranet:From there, click on Sites -> Advanced, then add the websites of interest… there are 2 ways you could do this addition – first way is to specify each website (protocol + hostname), for example:http://nw-portal.example.comhttps://sap-solman.example.com…and so on, accumulating items as you discover the websites where AD-based SSO should work.Another way is to use generalise using wildcards, and also we can generalise by not specifying a protocol – i.e. we cover both the HTTP and the HTTPS cases, and can get away with a one-line addition… e.g. if all our relevant websites are subdomains of example.com then:*.example.com[Note that if your main domain, example.com for uhh, example… if it also offers authentication of SSO requests, then you would likely add “example.com” as an extra item, since it isn’t covered by “*.example.com” due to the dot after the wildcard].Anyway then we can close the windows (Close -> OK) to get back to Internet Properties window, and then for Security->Local intranet, we click on Custom level… scroll down to User Authentication and make sure Logon radiobutton “Automatic logon only in Intranet zone” is on. Then OK to close the window. Then switch to Advanced tab and scroll down to Security section and make sure “Enable Integrated Windows Authentication” is on. Then OK to close the Internet Properties.If you close then reopen Edge and Chrome, they will now be able to use the computer’s Kerberos TGT (ticket granting ticket) to authenticate to the named server/protocol combinations.It might be that the option to Add websites in the Local intranet -> Sites dialog box, is greyed out with a message saying that this setting is managed by your organisation’s System Administrators. If so, you could ask your admins to rollout a policy that includes the needed websites; or you can check out the other solutions in this blog. Windows HKLM Registry approach (Edge, Chrome)For this approach, you need to have local administrator rights to your computer. Two ways to make the changes are now described, before that though: close Edge and Chrome completely (check and take action in Task Manager if needed).https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authserverallowlist The first way, is to open a Command Prompt in Run as Administrator mode, then run the following two commands, replacing “*.example.com,example.com” with the list relevant to your own organisation – you can specify actual servers and/or use wildcards:reg add HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftEdge /v AuthServerAllowlist /t REG_SZ /d *example.com,example.com /reg:64 /freg add HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome /v AuthServerAllowlist /t REG_SZ /d *example.com,example.com /reg:64 /fThen restart Edge and Chrome, and check the policy has been picked up by entering the relevant URL for each browser:edge://policyorchrome://policy Now you should be able to logon to the websites that use AD-based Kerberos for SSO logon (assuming of course that the Kerberos configurations on the server-side are correct).The other way to do this config, is to open the app called ‘regedit’ (Registry Editor) and from there implement the same stuff as specified in the commands given above or relying on the Microsoft advice in the link above. Leaving that as an exercise for the reader.See Appendix A: Other browser properties for other properties of Edge and Chrome that may also be relevant to configure. Windows – and MacBook – using FirefoxIf you do not have the rights to implement solutions for Edge and Chrome, or if you just prefer using Mozilla Firefox, then this solution might be useful…Open Firefox and enter the URL:about:configClick past the warning message. Search for the key:network.negotiate-auth.trusted-urisEnter some relevant value – you can enter a comma-separated list, or a generic wildcard value (no asterisk needed though), for example:nw-portal.example.com,sap-solman.example.comor:example.comHit <Enter> to save your changes. And that is all that should be needed. Now you can SSO into those websites that are accepting AD-based Kerberos logons. [Be aware that to SSO into a second website using a different authentication server, probably you will need to create a new Firefox session e.g. a guest session, so that Firefox doesn’t offer the second server an (invalid, in the second server’s opinion) token from the first server].See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity. MacBook using FirefoxThe configuration steps are exactly the same as for Firefox on Windows, so refer to previous section above “Windows – and MacBook – using Firefox”.By implementing this solution, you would typically be replacing the original authentication failure (HTTP 401 Unauthorised, returned because the website received no AD-based Kerberos credentials), as a result of which the website falls back to asking for manual logon:…so yeh, we’re replacing that HTTP 401 with successful SSO logons to the website using AD-based Kerberos, thanks to our minor config change. See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity. MacBook using SafariSo far, this combination has always worked out of the box for me in various work environments, so I don’t have any advice on how to configure Safari for AD-based Kerberos logins, as never had any need to investigate that. Anyway it seems that Safari relies on Apple’s Kerberos SSO Extension implementation:https://support.apple.com/en-gb/guide/deployment/depe6a1cda64/webFYR: on MacBook you can view your AD-logon details using the app called “Ticket Viewer”, or in Terminal you can run the commands:klistklist -v…to see information e.g. about e.g. the krbtgt (Kerberos Ticket Granting Ticket). MacBook using Chrome and Edge The solution is quite easy (though like most things that look easy, finding the solution wasn’t that easy).Close Chrome and Edge. Open the Terminal app, and run the following commands, replacing “*.example.com,example.com” with the relevant list of servers and/or wildcard entries that fit your own organisation’s needs best:defaults write com.google.Chrome AuthServerAllowlist “*.example.com,example.com”defaults write com.microsoft.Edge AuthServerAllowlist “*.example.com,example.com”These commands add an entry to the respective plist files:~/Library/Preferences/com.google.Chrome.plist ~/Library/Preferences/com.microsoft.Edge.plist(Xcode is the best app for viewing those plist files).Anyway now you can re-open Chrome and Edge, and if you like you can check that the relevant policy was uploaded by the browser using the relevant URL:chrome://policyedge://policyNow your AD-based Kerberos SSO into relevant websites should work fine. See (below) Appendix A: Other browser properties in case similar work needs to be done for those other properties. [You can use Guest sessions, or switching between Chrome personas, if you want to access multiple different websites while avoiding the trap where the first website’s tokens are offered to the second website for that second website to reject them :)]. Xubuntu and KerberosXubuntu Desktop distro is a popular variant of Ubuntu Desktop (difference is only in the Desktop Manager – actually I obtained the Xubuntu Desktop by installing arm64 Ubuntu Server, and then installing the Xubuntu packages).First we need to set up the client machine’s Kerberos functionality:https://documentation.ubuntu.com/server/how-to/kerberos/basic-workstation-authentication/sudo apt install krb5-user sssd-krb5We give the “realm” (which in my case is the hostname of the Kerberos server), and hit <Enter>For us, it is enough to be able to obtain a Kerberos ticket “on demand”, so we skip the sssd-configuration and instead just test the ‘kinit’ utility:kinit <ADUSER>@<Kerberos.server>Then check if the krbtgt (Kerberos Ticket Granting Ticket) was obtained:klistWe probably also need to specify explicitly, in the main Kerberos config file, where the Ticket cache is (filepath and syntax visible via ‘klist’ in above screenshot)… so let’s do that:sudo nano /etc/krb5.confAdd the relevant value, here is an example:default_ccache_name = FILE:/tmp/krb5cc_1000Ctrl+O, Ctrl+X to save and exit from the editor. Xubuntu ChromiumWe can use the advice from this Ask Ubuntu thread:https://askubuntu.com/questions/1204571/how-to-install-chromium-without-snap sudo add-apt-repository ppa:xtradeb/apps -ysudo apt updatesudo apt install chromium[Yes that is Chromium, not Chrome… as of September 2025 when doing these POCs, no arm64 Chrome for Ubuntu-family desktop distros available… so we take Chromium, which is the upstream browser project from which Chrome (and Edge) are derived].If like me you are running this Linux distro as a VM that is not pre-configured by your organisation, then you may want to export your organisation’s CA and Root CA .pem files (e.g. in the host machine, go to some intranet website and export the certificates from there), and then import them into your Linux Chromium browser, from here:chrome://certificate-manager/localcertsResult of your imports should show up in “Installed by you” section of the settings…[For non-GUI-browser situations, e.g. when using curl or wget, there is a different solution for importing the certificates to the Ubuntu filesystem, but that is outside the scope of this blog].Anyway we can then start up Chromium from the command line supplying the temporary list of Authenticating-by-Kerberos servers, as a comma-separated list and with relevant wildcard use according to your needs:chromium –auth-server-allowlist=”*.example.com,example.com”So this should work (try Refresh in case the first time the browser uses some previously cached “manual login” page). But it would be better to implement a solution that doesn’t require the user to specify options from the command line each time they open Chromium, so here is the more permanent solution… I used these pages of advice, note that there are Ubuntu-specific and Chromium-specific paths involved…https://support.google.com/chrome/a/answer/9027408?hl=en https://www.chromium.org/administrators/linux-quick-start/ For this example we will use the managed_policies.json file i.e. make the new policy mandatory for users…sudo mkdir -p /etc/chromium/policies/managedcd /etc/chromium/policies/managedsudo touch managed_policies.jsonsudo pico managed_policies.jsonAdd the policy:{    “AuthServerAllowlist”: “*.example.com,example.com”}Ctrl-O, Ctrl-X to save and exit from the pico-editor.Now we can start Chromium up e.g. from the GUI Menu, under category Internet, and check that the new policy was loaded by going to chrome://policy Now our SSO via AD-based Kerberos works fine. Note that to switch from one SSO over AD-Kerberos workflow to one provided by another server, you may need to close Chromium then re-open it.See Appendix A: Other browser properties for other properties of Chromium that may also be relevant to configure.  Xubuntu Firefox… the right kind of FirefoxRecent editions (e.g. 24.04 LTS) of Ubuntu Desktop are delivered with the so-called “snap”-package variant of Firefox already installed; however I found that this “snap”-Firefox doesn’t work with Kerberos, not for me anyway. So instead, we should get rid of “snap”-Firefox and replace it with “apt-repo”-Firefox. Here is the advice I used:https://askubuntu.com/questions/1399383/how-to-install-firefox-as-a-traditional-deb-package-without-snap-in-ubuntu-22″[…]sudo add-apt-repository ppa:mozillateam/ppaThen, copy and paste the following code in a terminal in one go (don’t copy-paste line by line) to prioritize the apt version of firefox over the snap version.echo ‘
Package: *
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001

Package: firefox
Pin: version 1:1snap*
Pin-Priority: -1
‘ | sudo tee /etc/apt/preferences.d/mozilla-firefoxNext, remove the snap version of firefoxsudo snap remove firefox[…]Install Firefox with apt.sudo apt install firefox[…]”Ok good – note that now we cannot open Firefox as default Web Browser directly from top-level GUI menu (as “Web Browser” refers to deleted snap-version); instead we can use the GUI category “Internet” (Chromium is also listed under this category) and open our new Firefox item there… or type “fire” in the menu search bar and choose Firefox… or we can start the new Firefox from command line:firefoxThen we should import any needed CA certificates of the organisation…  from the “I-ching” icon in top-right of Firefox menu bars, choose Settings, then type “cert” so that “View Certificates” option comes up:Open the View Certificates dialog and choose Import.. and then, well, import the needed certificates. Once done, those are visible in View Certificates (scroll through list till you see them).Now we are at the stage where we can do the same procedure as with Firefox on other OSes above…enter the URL:about:configClick past the warning message. Search for the key:network.negotiate-auth.trusted-urisEnter some relevant value – you can enter a comma-separated list, or a generic wildcard value (no asterisk needed though), for example:nw-portal.example.com,sap-solman.example.comor:example.comHit <Enter> to save your changes. And that is all that should be needed. Now you can SSO into those websites that are accepting AD-based Kerberos logons.   See Appendix A: Other browser properties for a second Firefox property that can sometimes be relevant for about:config activity. Appendix A: Other browser propertiesFYR: in case your Kerberos setup involves credential-delegation servers, and/or in case you need to specify an Authentication Scheme in e.g. Edge (cases I have no actual experience with) then the following Keys and their values may be of interest:https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authnegotiatedelegateallowlisthttps://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/authschemes[These links are about Edge, but in practice Edge, Chrome, and Chromium are a family – Edge and Chrome based on Chromium – so there are many properties that are identical by name and function].Chrome, Edge: AuthNegotiateDelegateAllowlistAuthSchemesFirefox equivalent of AuthNegotiateDelegateAllowlist (via about:config we can modify this key):network.negotiate-auth.delegation-uris… The AuthNegotiateDelegateAllowlist Keys (and Firefox equivalent) would have as value typically some hostname such as: authserver.example.comIf your organisation is using other paradigms for authentication such as NTLM, then you might need or want to specify the AuthSchemes Key with the relevant schemes as values in comma-separated form, for example with Kerberos and NTLM you would have:negotiate,ntlm Appendix B: SAP Secure Login ClientAlthough this blog is focused on browsers, we note that SAP Secure Login Client can also use AD-based Kerberos tokens for SAPGUI SSO. Normally, the Secure Login Client obtains the needed Kerberos token from the user’s cache… however, we had a situation during initial testing of Windows 11, where for some reason this automatic retrieval of Kerberos token was not working for a while. So, in such cases, here is a possible (though not very elegant or scalable) workaround… In the Windows In-Tray -> click on the wee icon with a white tick-mark on a blue diamond background (SAP Secure Login Client):Double-click on the relevant item that says “Kerberos Token”:Enter your AD-credentials and click “OK”:Assuming the AD logon succeeds, now your AD-based Kerberos SSO logons to SAP systems via SAPGUI sessions should work again, as SAP Secure Login Client has the Kerberos token it needs.    Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog