Unable to log into CiscoWorks

Answered Question
Aug 4th, 2007

I've just tried to install Qos Policy Manager into my existing installation of CiscoWorks and now i'm unable to login.

After entering login credentials, i'm unable to get to the next main screen.

All CiscoWorks services have started, and they are set to the correct startup setting. I've looked at some of the logs and see that authentication is successful.

I'm unsure where to look for any other errors.

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 9 years 4 months ago

It looks as though there is a problem with Apache connecting back to itself. I've seen this in the past when the Windows system admin configured the machine using the IE Admin Kit to either disable cookies for all accounts, or add a global proxy setting.

You should first verify that the server's hostname, SITEPROT1 properly resolves to the correct IP address, and that IP address resolves back to SITEPROT1. Use the NMSROOT\bin\resolver.pl script for this:

NMSROOT\bin\perl NMSROOT\bin\resolver.pl SITEPROT1

Next, perform the same lookup tests for localhost and 127.0.0.1. Then, check to see if there are global proxy or cookie policies being enforced on the server. The easiest way to do this is use an account like local Administrator. Set its cookie policy to always allow cookies, and disable any proxy settings. Then, go to the Services control panel, and edit the properties for CiscoWorks Web Server service. Go to the Log On tab, and have the service logon as Administrator (with the correct password). Then restart CiscoWorks Daemon Management, and see if that helps.

If that gets things working, you will need to work with your Windows admin to relax the cookie and/or proxy settings. In particular, the web server typically runs as SYSTEM, so this user needs to have a more lenient web browser policy.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Sun, 08/05/2007 - 10:11

So the login screen is left being displayed, and the browser is perpetually loading? what version of Common Services are you using? Which version of QPM did you install? What platform? What CiscoWorks login module are you using?

mbstrauss Sun, 08/05/2007 - 16:19

That would be correct. I'm honestly not too sure what exact version of Common Services is installed, it is the latest version 3.0 though (3.0.5?), i did a 'check software' recently and it didn't detect any new versions at the time

I installed QPM 4.0 SMB version and it's running on Windows 2003 Server

Not too sure about the CiscoWorks login module you're referring to.

I've also noticed now that i have to reset the causer password to restart the Daemon Manager

Thanks in advance again

Joe Clarke Sun, 08/05/2007 - 16:26

The output of "set" from a DOS command line, the NMSROOT\MDC\etc\regdaemon.xml file, NMSROOT\MDC\Apache\logs\error.log file, NMSROOT\MDC\tomcat\logs\stdout.log file, and the NMSROOT\www\classpath\com\cisco\nm\cmf\security\jaas\JaasConfigModule file will help. Note: if the data in regdaemon.xml is too sensitive to share on a public forum, you should open a TAC service request with the same data so that they can analyze this problem further.

mbstrauss Wed, 08/08/2007 - 22:08

Find attached the requested log files ... hopefully there's something there that's obvious to the reason why this problem is now occurring.

I have actually uninstalled QPM and the problem is still present.

On another note, the 'JaasConfigModule' is not present in my installation

mbstrauss Thu, 08/09/2007 - 15:05

I have also noticed that after trying to logon, the process will stop trying to access CSCOnm/servlet/com.cisco.nm.cmf.servlet.CsAuthServlet

Correct Answer
Joe Clarke Thu, 08/09/2007 - 19:33

It looks as though there is a problem with Apache connecting back to itself. I've seen this in the past when the Windows system admin configured the machine using the IE Admin Kit to either disable cookies for all accounts, or add a global proxy setting.

You should first verify that the server's hostname, SITEPROT1 properly resolves to the correct IP address, and that IP address resolves back to SITEPROT1. Use the NMSROOT\bin\resolver.pl script for this:

NMSROOT\bin\perl NMSROOT\bin\resolver.pl SITEPROT1

Next, perform the same lookup tests for localhost and 127.0.0.1. Then, check to see if there are global proxy or cookie policies being enforced on the server. The easiest way to do this is use an account like local Administrator. Set its cookie policy to always allow cookies, and disable any proxy settings. Then, go to the Services control panel, and edit the properties for CiscoWorks Web Server service. Go to the Log On tab, and have the service logon as Administrator (with the correct password). Then restart CiscoWorks Daemon Management, and see if that helps.

If that gets things working, you will need to work with your Windows admin to relax the cookie and/or proxy settings. In particular, the web server typically runs as SYSTEM, so this user needs to have a more lenient web browser policy.

mbstrauss Mon, 08/20/2007 - 14:51

I've checked using the lookup tests and they are properly resolving. I am however still checking through if there is any problems with our network policies in regards to allowing cookies and proxy settings.

I am now however eventually getting a 'read timeout' error for the following after the login screen:

http://siteprot1:1741/cwhp/cwhp.applications.do

mbstrauss Tue, 08/21/2007 - 20:00

Just an update, changing the services log on credentials to run as administrator worked!

However, i'm just curious to know why this has happened, since i'm sure it was set to run as local system previously.

Also, i'm also encountering a new kind of problem whereby i need to reset the ca user password all the time to be able to restart the CiscoWorks Daemon Manager. I'm worried that if this server has a reboot, the services will not automatically start as the daemon manager will error out when trying to start.

Joe Clarke Tue, 08/21/2007 - 23:13

As I said, you probably had a global cookie or proxy setting enabled on this server which affected the SYSTEM user. You may still have some kind of policy in place that locks out the casuser account, changes its password, or adjusts the local security policy. resetCasuser.exe fixes the password in SAM and in the CiscoWorks registry as well as adjusts the local security policies to allow for casuser and the casusers group to do what they need to do.

So, you should contact your server/security admin, and find out what they are doing to this server that could affect user accounts and local security policies.

Actions

This Discussion