06-28-2012 07:36 PM - last edited on 03-25-2019 09:03 PM by ciscomoderator
Migrated TMS 13.2 with TMSPE from physical server to VM 2008 R2, which went fine, however, VCS-C is now giving me HTTP exception status for all provisioning services; users, phonebooks and devices.
Status: failed
Response: HTTP Exception
Reason: (400) HTTP Error: WWW-Authenticate
And yet, TMSPE diagnostics in TMS shows no alarms; it's all green.
TAC is working on it though.
Anyone seen this before ?
/jens
Solved! Go to Solution.
08-25-2012 02:24 AM
Thanks for sharing!+5
/Magnus
Sent from Cisco Technical Support iPhone App
08-25-2012 07:36 PM
Magnus, are you thinking this might fix my problem with tmspe?
Darren
Sent from Cisco Technical Support iPhone App
08-25-2012 11:23 PM
Hi Darren
I believe the problem you are experiencing is different. You don't have a problem getting the VCS and TMS to communicate. The problem in your case is the phonebook synch with tmspe. I would not have done this at least before we have done some tests
/Magnus
Sent from Cisco Technical Support iPad App
02-06-2013 06:31 AM
Hi Guys,
Only in rare cases you should need to re-intsall all of TMS and TMSPE in order to fix this error. I would try the below steps first.
This seems to be an issue with negotiating the authentication type. I have seen this quite a few times within TAC and the fix is to change the priority of the provider under tmsagent by moving NTLM above Negotiate. Further instructions are below. This only works with IIS 7.5 as IIS 7.0 doesn't have the providers in the GUI and would have to be modified differently.
On the TMS server running TMSPE, open IIS manager.
On the left pane, select the tmsagent virtual folder under the default web site.
In the center pane, double click Authentication.
Select Windows Authentication.
On the right hand pane, select Providers.
Move NTLM above Negotiated
Select OK to save your settings.
This does not require a reboot or restart of any services.
This has worked many times with many cases.
Chad Johnson
Message was edited by: Chad Johnson
02-06-2013 03:19 PM
Hi Guys,
After about 4 hours on a case, I have figured out what is causing this issue. I am able to replicate this in the lab as well.
This issue is what is sent in the 401 Unauthorized from TMS. The working message stream is as follows:
1. VCS sends 4 GET messages to TMS (1 for each TMSPE service)
2. TMS sends a 401 Unauthorized with the following 3 lines:
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic
3. VCS sends 4 GET messages with a selected authentication method
The failed message stream is as follows:
1. VCS sends 4 GET messages to TMS (1 for each TMSPE service)
2. TMS sends a 401 Unauthorized with the following 3 lines:
WWW-Authenticate: Basic
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
3. VCS doesn't send anything
Notice how Basic authentication is listed first. When the VCS receives the 401 it doesn't send the GET messages at all. This is the issue at hand. The VCS is expecting Basic to be listed in the 3rd spot. You can still change the order of NTLM or Negotiate by following the steps in my previous post.
To change the order of the Basic message you need to change the order in which it lists in the modules portion of IIS.
From what I have found you will most likely have to modify the applicationHost.config file. In the GUI you can move this up using the modules section but I have found that the items are locked and are unable to move in the GUI.
The file is located in C:\Windows\System32\inetsrv\config
To fix it I have written the following steps below:
1. Backup the applicationHost.config file
2. Stop the WWW Publishing service on the Windows server
3. Edit the applicationHost.config file by opening it in Notepad
*WARNING: This file contains a lot of information that pertains to IIS. If the file is not modified correctly you might have to end up uninstalling and re-installing everything.*
4. Search/Find the string "
You should find only two of them
Look for the one that looks like this:
5. Look below the modules tag and find the line with:
6. Move the above line in step 5 line anywhere above the following two lines still underneath the
If the BasicAuthentiacationModule line is below the WindowsAuthenticationModule lines in the file, the Basicauthentication line in the 401 from TMS will be at the top causing failure.
7. Save the file which is located in C:\Windows\System32\inetsrv\config
8. Start the WWW Publishing service
9. Disable and re-enabled the services on the VCS
Let me know if you have further questions.
Chad
02-06-2013 06:08 PM
Chad,
Where were you like 6 hours ago :) Had to do a full uninstall & re-install of TMS, IIS & PE to resolve this :) Anyway, is this considered a bug in the VCS or what? Seems very restrictive that the VCS must have the auth strings in a very specific order, or is this normal? On another note, thank you so much for posting back on this, I love when you guys share these tidbits, makes our calls a lot faster and we don't have to bother you guys :)
Thanks,
Justin
Sent from Cisco Technical Support iPad App
02-07-2013 06:05 AM
Hey Justin,
I am opening the bug on the VCS as I don't think that it should matter the order. I my opionin the VCS should read all 3 authentication types then chose what is best. I will keep everyone posted of the bug. Looks like Brian was helpping you out yesterday. I told him that we were going to figure this out but he informed me that you guys had already done the re-install. Eitherway, no more full re-installs!
Chad Johnson
02-08-2013 06:32 AM
Chad,
Thank you so much for all the time you have put into this. Let us know what you find.
Thank you,
Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
e/v: justin.ferello@kbz.com
02-14-2013 05:33 AM
Hi Chad
Thanks for the investigation on this the root cause seems to in fact be the Basic coming in first. However I have a little more user friendly way of resolving the issue.
I had a case where this error was occurring and I modified the applicationHost config file in the same location path as you mentioned. I tested in the lab first and I was able to reproduce. But for this customer it did not work when we modified the file, in the end I just removed all content from the file and it did not seem to affect the IIS server at all as it was restarting happily ever after and showing the same error. We tried to modify the provider, disable windows authentication and re-enable it. Nothing seems to work.
So the file path might not be the file IIS is looking at all the times so to be 100% sure open the IIS manager and click on the server (because the modules are inherited from here).
In the window on the right hand click on Modules
Then on actions click on View Ordered
So in this case the error will occur since Basic comes before Windows authentication as Chad figured out was the root cause. And this was the case for this customer as well.
Then just mark the module and move it above Windows authentication
No need to restart anything, just untick one of the TMSPE services, save and re-enable it and it should work.
Easy to reproduce as well by moving it below. Seems like there is several ways of bypassing this issue now in a few seconds rather than doing a complete reinstall.
/Magnus
02-25-2013 09:11 AM
Magnus,
running in the same error with my TMS 14.1.1 installation and TMSPE.
Read the thread carefully and must say that BasicAuthenticationModule is before WindowsAuthenticationModule.
Do you have any additional tips to solve this problem?
Regards
Juergen
02-25-2013 09:52 AM
Hi Juergen,
When you get a packet capture from the TMS, what is the order of the www-authentication messages in the 401 that TMS sends back to the VCS?
Thanks,
Chad
02-26-2013 12:21 AM
hi Chad,
I only see NTLM in the authentication flow.
Juergen
02-26-2013 08:06 AM
By default the TMS needs has Basic & windows authentication (negociate & NTLM) enabled on the tms and tmsagent virtual directories from within IIS. It doesn't seem that Basic authentication has been enabled for tmsagent. If it is enabled, are their group policy settings on the Windows Server that are enabled that require a higher level of authentication such as FIPS?
The IIS virtual directory authentication or directory security are documented on page 33 of
Chad
02-27-2013 12:39 AM
Chad,
Basic auth is enabled. I checked and configured it as you documentent abobve posts above:
The TMS server itself is a standalone Win2008 machine without any other services running on, there is no active directory, no FIPS.
But it seems that Basic Auth isn't working, if I do from the VCS a "wget --user --password http://tms.server.ip/tmsagent" I get an 401 error.
02-27-2013 01:44 AM
Found the error!
To solve the problem, use Magnus advisory of using IIS Manager. Editing the config directly and moving Basic Auth on top
didnt help for me.
@Cisco, maybe you can update the installation files of TMS to solve this problem correctly.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide