You are viewing limited content. For full access, please sign in.

Question

Question

Does single sign on or authentication negotiation not work on Chrome in Weblink?

asked on February 6, 2014

I followed several directions on how to get Chrome to work with NTLM Authentication and cannot get this to work correctly.

 

We'd like for our users inside the domain, when using Chrome, to be able to have single sign on when accessing Laserfiche Weblink.  In IE it works fine and we have added NTLM modifications to the about:config for Firefox.  

 

Problem:

I know Chrome reads off the Trusted site list of IE and uses those sites to automatically pass NTLM.  I believe NTLM is working; however, whatever authentication level is after NTLM that is required is not working.

 

Tested:

  1. Added sites to IE's trusted site list
  2. Did a registry edit for HKLM > Software > Policies > Google > Chrome
    1. Added AuthNegotiateDelegateWhitelist and added our weblink server to the value list
  3. Tried adding a manual switch to Chrome browser: --auth-server-whitelist:(with server name and IP name)

 

Result:

  1. From option 3 above: Using Chrome without any modification, accessed the IP for weblink server – it pops up asking me to type in credentials.  I then used a Chrome shortcut and passed --auth-server-whitelist:10.x.x.x (our weblink server IP)- it then did not require me to enter credential; however, passed me onto the page that had the permission denied message.  This lets me to believe that NTLM is working fine, but a second authentication level is preventing the whole process from working correctly.
0 0

Answer

APPROVED ANSWER
replied on February 14, 2014 Show version history

For Chrome, please reference this page and note where it states

Some services require delegation of the users identity (for example, an IIS server accessing a MSSQL database). By default, Chrome does not allow this. You can specify --auth-negotiate-delegate-whitelist to enable it for the servers. 
 
Delegation does not work for proxy authentication.
0 0
replied on July 22, 2015 Show version history

I would like to add to this in case others are having the same issues.  Here is what I had to do:

 

IE - works by default, leave it alone.

Firefox

  1. Navigate to about:config - confirm warning,
  2. Search for NTLM, find (if it doesn't exist, create it):
    • network.automatic-ntlm-auth-trusted-uris
      • enter in your servers/domains
      • for multipel values, use comma separated
      • e.g. "server1,server2,domain1.com,domain2.com,*.domain3.com" - without the quotes.  Wildcards are acceptable.
  3. Search for Negotiate
    • network.negotiate-auth.delegation-uris
      • enter in same list as #2
    • network.negotiate-auth.trusted-uris
      • same list


Alternatively, you can also make a batch logon script to replace a custom user.js file that should be located in each users' %appdata%\Mozilla\Firefox\Profiles\<ff-uid>.default\user.js

user.js file ::

user_pref("network.automatic-ntlm-auth.trusted-uris", "server1,server2,domain.com,domain2.com,*.domain3.com");
user_pref("network.negotiate-auth.delegation-uris", "server1,server2,domain.com,domain2.com,*.domain3.com");
user_pref("network.negotiate-auth.trusted-uris", "server1,server2,domain.com,domain2.com,*.domain3.com");
user_pref("browser.search.defaulturl","http://www.google.com/");
user_pref("browser.search.defaultenginename","Google");
user_pref("security.warn_viewing_mixed",false);

The last 3 lines in the above code are optional.

 

Batch file for replacing user.js (e.g. firefox-user-js.bat)::

if exist "%APPDATA%\Mozilla\Firefox" for /D %%F in ("%APPDATA%\Mozilla\Firefox\Profiles\*") do copy /y "\\network\location\of\your\\user.js" "%%F"

 

insert this to your logon script to call the batch file ::

call "\\location\of\the\batch\file\firefox-user-js.bat"

 

Chrome

This one for whatever reason took me the longest to figure out because everyone gave the same solution, but it never worked.  If you use Google Chrome variables in HKLM\Software\Policies\Google\Chrome - it wont work (at least it didn't for me).  The only way I got it to work was inserting the keys into the HKCU instead. I used GPMC with item-level targeting as it was readily available and easy for me.  You can export the keys, then use a .reg file and run it at logon as well.  Since I used GPMC, I will provide directions for the item-level targeting.

Here are the steps:

  1. Create or modify an existing USER Configuration Policy
  2. Traverse to User Configuration > Preferences > Windows Settings > Registry
  3. Insert in a new Collection Item (optional)
    • Call it Google Chrome (or whatever you want)
  4. Inside the Collection Item, insert new Registry Key - you need two keys
    Key 1 ::
    
    Action: Create
    HIVE: HKEY_CURRENT_USER
    Key Path: Software\Policies\Google\Chrome
    
    Value Name: AuthNegotiateDelegateWhitelist
    (don't check default)
    
    Value Type: REG_SZ
    Value Data: <insert the comma separated list you had for firefox>
    Key 2 ::
    
    Action: Create
    Hive: HKEY_CURRENT_USER
    Key Path: Software\Policies\Google\Chrome
    
    Value Name: AuthServerWhitelist
    (dont check default)
    
    Value Type: REG_SZ
    Value Data: <insert same comma separated list you had from firefox/last key>
    

For item-level targeting, on each key that you create - there is a "Common Tab".

Common Tab - Do this for each key, with their own criteria::

  1. Select Item-level Targeting
  2. Go into Targeting
  3. Add new item > Registry Match
  4. Select "is not" from Item Options
  5. Fill in the following:
Match Type:
Value exists

Hive:
HKEY_CURRENT_USER

Key path:
SOFTWARE\Policies\Google\Chrome

Value name:
AuthServerWhitelist  // or // AuthNegotiateDelegateWhitelist - whichever key you are working on

Value type:
Any

The total value should say "the registry value HKCU\Software\Policies\Google\Chrome\<key name> does not exist" on each key that you did targeting.

I have tested all of the above on our network and all three browsers are now working the way I wanted it to.  Good luck.

3 0

Replies

replied on February 6, 2014 Show version history

If WebLink and the Laserfiche server are on different machines, then you need to make sure that the browsers are authenticating with Kerberos and not NTLM.  In the IIS management tool, open the authentication settings for the WebLink8 application.  Under the providers for Windows authentication, make sure that Kerberos is there and NTLM is not.

 

We don't use WebLink internally at Laserfiche, but our Web Access server can do SSO with Chrome (with WA and LFS on different machines).  I had to add some registry keys (on the client) to get it to work.  I looked at the server configuration, and the options are a little different - it's Windows Datacenter edition, which doesn't have a UI for providers, but judging from the headers and kernel-mode options, I'm guessing that both NTLM and Kerberos are enabled.

1 0
replied on February 6, 2014 Show version history

Yes the Weblink & LF Server are on different machines.

 

Thank you for the suggestion.  IIS had Negotiate & NTLM originally configured.  After enabling Negotiate:Kerberos - it required me to disable Kernel-Mode Authentication and thus broke NTLM for IE & Firefox.

 

Our rep has found this article regarding Chrome + Kerberos and by design, it may not work?  I would like to know if someone out there actually has gotten this to work correctly.

0 0
replied on February 7, 2014

Anyone here tried to use Chrome in a SSO environment where Laserfiche and WebLink are on separate servers?  The system is working if the browser is IE or FireFox, but if they use Chrome (many of their users are wanting to use Chrome) then they get an access denied.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.