Office 2013 displays a LOT of credential prompts with Smoothwall on NTLM

[AngryTechnician]

Our Smoothwall is configured for NTLM authentication, and this generally works fine for us. However, with Office 2013, I'm seeing a LOT of requests for proxy auth credentials:

 

 

The hostname varies, and the request will appear just by opening documents, or even just by opening Excel with a blank document. I've already added the following to our noauth lists, which has eliminated most of the auth requests:

 

officeimg.vo.msecnd.net
office.microsoft.com
odc.officeapps.live.com

 

However, I've just found that clicking any URL in a document, or in OneNote, will prompt for credentials (unless the site is on the noauth list). In this case, the hostname listed after "Connecting to proxy server" is always the host specified in the URL.

 

If I supply valid credentials, Office just asks for them again, as if they are invalid. However, if I click cancel, the URL then passes to IE and opens fine.

 

I know Office 2010 was picky with NTLM auth (YouTube embedding never worked for us, for example), but it never prompted just for clicking on a link before. Office 2013 does, and I can't deploy it like this.

 

Suggestions?

[sonofsanta]

I have no idea if this will help but it doesn't sound a million miles away from problems I've been having with Moodle, NTLM & Office 2010.

 

Does stopping the WebClient service make the prompts go away?

 

Hotfixes that seemed relevant (although they didn't solve my problem, they may shed light on your issue): Prompt for Credentials When Accessing FQDN Sites From a Windows Vista or Windows 7 Computer and Problems may occur when you try to open an Office document from a Web site hyperlink in a 2007 Office application

[plexer]

Would switching to kerberos auth work?

 

Ben

[AngryTechnician]

Does stopping the WebClient service make the prompts go away?

 

The WebClient service wasn't started when I checked it. Starting it had no effect on the problem.

 

Would switching to kerberos auth work?

 

That's top of my list of things to try this afternoon. Any hints on side-effects this might have?

[plexer]

The WebClient service wasn't started when I checked it. Starting it had no effect on the problem.

 

 

 

That's top of my list of things to try this afternoon. Any hints on side-effects this might have?

 

I haven't tried it

 

Ben

[sonofsanta]

The WebClient service wasn't started when I checked it. Starting it had no effect on the problem.

 

That's top of my list of things to try this afternoon. Any hints on side-effects this might have?

 

If it wasn't started then nevermind; turning it off would have been the fix. WebClient is the newer way of authorizing that sometimes causes problems (according to those kb articles), turn it off and it falls back to older methods. This is why clicking Cancel works - it gives up trying whatever auth method it's using and uses an older method that does work, hence you then get the page load.

 

Kerberos auth worked fairly smoothly for me, any user specific rules you have set up will need updating from username to [email protected], and make sure your Smoothie is fully up to date as some updates came out earlier this week that helped improve it. Any Local Users you have set up to override specific user group membership won't work, but you can set Guardian policies against specific users fine (once you're updated). I had an issue with my staff AD group not mapping to the Smoothwall group, but relinking Smoothwall to another AD group containing all staff made that work again.

 

Think that was everything that came up for me, easiest way to test is just to set up a new auth policy on a new port and then change your proxy settings on a test machine to use that port instead.

[AngryTechnician]

OK, testing with Kerberos on an alternate port eliminates the problem, so that looks like the way forward. Will do some further testing and update if there are any problems.

[AngryTechnician]

OK, just to report back: switching to Kerberos was relatively pain-free and is working well for us. Sticking with NTLM just wasn't feasible due to the above problem, so I suspect anyone who runs into the same problem will find that switching auth method is the only realistic solution.

[Duke5A]

We haven't moved to Office 2013 yet, but I've already started to see issues like this. Out of the blue Outlook 2010 seemingly at random starts asking for user credentials. Same symptoms as you described: asking for credentials, no matter what you give it it fails, and clicking cancel makes it work. I didn't think that it might be trying to make a web connection. I guess I'll be moving my Squid boxes over to Kerberos next week.

[OverWorked]

OK, just to report back: switching to Kerberos was relatively pain-free and is working well for us. Sticking with NTLM just wasn't feasible due to the above problem, so I suspect anyone who runs into the same problem will find that switching auth method is the only realistic solution.

 

What exactly did you do to switch Smoothwall over to Kerberos?

 

I'm looking at Web proxy » Authentication » Manage policies.

 

Do I just change the non-transparent auth from NTLM (TS compatible) to Kerberos (TS compatible)?

 

Is there anything else?

 

Thanks.

[AngryTechnician]

OK, bringing together advice from a few different threads:

 

- DO NOT just change your auth setting from NTLM to Kerberos. It will probably not work, and I will point and laugh at you. Set up a new auth policy on a different port number and test Kerberos with a range of users first. Then test it again. Only once you are satisfied it is working should you change the auth setting on the port that your workstations are configured to use by default.

 

- The main prerequisite to using Kerberos as an auth method is for Smoothwall to be joined to your domain in Services » Authentication » Settings using the "Active Directory" type, instead of the "Active Directory (legacy method)" type. If you don't see the legacy method as an option, you need to run updates on your Smoothwall.

 

- Once you change from the legacy type to the new type, all users must log off and back on before their Kerberos token will be recognised by Smoothwall. Any users who logged on to their workstations before you switched to the new type will fail to authenticate to Smoothwall.

 

- Before you even get around to testing Kerberos on workstation, go to Services » Authentication » Control and run the configuration checks. Anything without a green tick next to it should be corrected first. Also, if you don't see a line with "Keytab created" and a green tick, Kerberos is not set up.

 

- Any user-specific policies will need to be edited to reflect that the username will be reported as [email protected] instead of just user

 

- The current Kerberos implementation on the Smoothwall does not correctly process usernames with spaces in. I believe this has been raised for a future patch, but for now, the only workaround at present is to rename user accounts so they have no space (luckily we only had 22 affected accounts).

 

- Local users on the workstation (such as the local admin account) will not be able to authenticate at all using Kerberos, and will have to use different proxy settings if you need access.

 

- Kerberos normally works better than NTLM (which is of course why I switched to it for use with Office 2013), but some software will still choke. Notably, Java works with NTLM but does not work with Kerberos. Until this is fixed (don't hold your breath), you will need to provide a separate NTLM port for Java to use. You can specify different proxy setting for Java using Java's deployment.config file.

Edited November 27, 2012 by AngryTechnician

[OverWorked]

Thanks very much, AngryTechnician! I just switched it over before you posted, and it all appears to work. The sky hasn’t fallen down. Here’s my experience, so far.

 

- DO NOT just change your auth setting from NTLM to Kerberos. It will probably not work, and I will point and laugh at you.

- I did just switch over, and it did work.

 

- The main prerequisite to using Kerberos as an auth method is for Smoothwall to be joined to your domain in Services » Authentication » Settings using the "Active Directory" type, instead of the "Active Directory (legacy method)" type.

 

I was already on “Active Directory” server type, so was OK.

 

 

- Once you change from the legacy type to the new type, all users must log off and back on before their Kerberos token will be recognised by Smoothwall. Any users who logged on to their workstations before you switched to the new type will fail to authenticate to Smoothwall.

 

All I experienced was a brief internet outage. Refreshing web pages got them back. I didn’t need to log off and on again.

 

 

- Before you even get around to testing Kerberos on workstation, go to Services » Authentication » Control and run the configuration checks. Anything without a green tick next to it should be corrected first. Also, if you don't see a line with "Keytab created" and a green tick, Kerberos is not set up.

 

All green, so OK. And still all green after switching to Kerberos.

 

 

- Any user-specific policies will need to be edited to reflect that the username will be reported as [email protected]er instead of just user

 

I don’t have any user-specific policies, so OK.

 

 

- The current Kerberos implementation on the Smoothwall does not correctly process usernames with spaces in. I believe this has been raised for a future patch, but for now, the only workaround at present is to rename user accounts so they have no space (luckily we only had 22 affected accounts).

 

I don’t have any usernames with spaces, so OK.

 

 

- Local users on the workstation (such as the local admin account) will not be able to authenticate at all using Kerberos, and will have to use different proxy settings if you need access.

 

I don’t have any local users, so OK.

 

 

- Kerberos normally works better than NTLM (which is of course why I switched to it for use with Office 2013), but some software will still choke. Notably, Java works with NTLM but does not work with Kerberos. Until this is fixed (don't hold your breath), you will need to provide a separate NTLM port for Java to use. You can specify different proxy setting for Java using Java's deployment.config file.

 

Java on websites is becoming increasingly scarce, and I can’t think of any Java applications we have. May have to cross this bridge when I come to it.

 

Any applications that struggle with authentication (e.g. Securenet), used another port to bypass authentication anyway. So They shouldn't be affected byswitching to Kerberos.

 

Office 2013 is now working without any annoyong proxy authentication messages.

Edited November 28, 2012 by OverWorked

[arron]

OK, bringing together advice from a few different threads:

- The current Kerberos implementation on the Smoothwall does not correctly process usernames with spaces in. I believe this has been raised for a future patch, but for now, the only workaround at present is to rename user accounts so they have no space (luckily we only had 22 affected accounts).

 

It has been marked as a bug by smoothwall.

[Jollity]

It has been marked as a bug by smoothwall.

Does anyone know if this has been fixed, or when it might be fixed?

 

It could be a major issue for us as most of our user names have spaces in, and we want to start installing Office 2013 soon.

[arron]

I checked after main update 53 and it's still broken here. I dont have any idea on when it will sorted, sorry.

[Minkus]

Regarding the Smoothwall Kerberos / NTLM issue, I believe it is possible for Smoothwall to support Kerberos and NTLM on a single port - would need some extra work on their part though but I *think* it might mean we don't have to configure Java any more.

 

Have posted a suggestion to Smoothwall's UserVoice forum here:

Support Negotiate authentication fully to allow Kerberos AND NTLM to be configured on a single port

If you'd like to see this, please support the suggestin by voting for it