Unable to login to Cacti

[nomanlan]

My Cacti has been running fine and collecting data, now I keep getting the login page asking for username and password. I thought I had forgotten the admin password so I ran the reset procedure
-----------------------------------------------------------------------
shell> mysql -u root -p cacti
Now execute the following SQL:

mysql> update user_auth set password=md5('admin') where username='admin';

Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> exit
Bye
------------------------------------------------------------------------

Still I am not able to login and keep getting the same username/password login dialog over and over. The manual says it's the so, this is a PHP session/cookie issue, I am not sure how to go about fixing it.

Any thought on what the problem might be and how to fix it?

[BSOD2600]

Read http://forums.cacti.net/viewtopic.php?t=11747 and repost.

The IUSR_ account needs modify rights to the php\sessiondata folder.

[nomanlan]

I re-verified and the "modify" permission for IUSR_Computer name to PHP/Session directory is still in tact. I went through the installation doc again, all access rights to directory and web pages are still set up properly. Any other suggestions?

[BSOD2600]

You didn't post your system info, like I asked.

Well not sure what else to tell ya... it's a php session issue. fire up Sysinternals FileMon and watch what is getting denied when you try to login. I bet you'll see its the c:\php\sessiondata directory...

[nomanlan]

I rerun filemon hoping to see some access denied error but everything seems to be in order, the filemon trace is attached for your review.

Operating System:

Windows 2000
Webserver: IIS 5.0
Cacti: 0.8.6j
Cactid: unknown, downloaded about 2 months ago
MySQL: 4.1
PHP: 5.2.3
RRDTool (Cygwin or Win32 version): 1.2.23
Net-SNMP: 5.4.1
Cygwin (cygwin1.dll version): 1.5.20

[BSOD2600]

I don't see any of cacti's files or even php being run in that log. Did you filter it out or not login to the cacti web page?

Run the following from the command prompt and paste the output: php -m.

[lyudell]

I don't know what I did, but all of a sudden none of my accounts can log into CACTI...access denied. I was doing a "batch copy" from admin and everything lost access to everything.

How can I regain control?

[BSOD2600]

ummm make sure the NTFS permissions are set correctly (read my install guide). If that doesn't work, you can always manually reset the cacti passwords with mysql admin.

[lyudell]

I'm running under windows and I think the permissions are OK. I think this is more like I've some how erased the permissions. The user table is OK, but the user_auth_perm table is empty...should it be?

[lyudell]

I got myself back in. Sorry ringing the alarm bell.

Somehow (and I'm still not sure how) I managed to remove all of the realm ids for the admin account. I don't know why this kept everyone else out, though.

I commented out the security check and managed to get in with one of the other admin level accounts which still had it's realm id's in place. Once in, I reset the admin security and everything is fine.

I'm now going to have to replenish the weight I lost in sweating this out....I'm thinking a Samuel Adams.

[k-y]

This has got to be a bug.

I just did a batch copy on a fresh install, granted, I probably should not have done a batch copy from admin to admin, but if the copy function worked correctly, copying permissions from a user into the same user shouldn't mess things up.

Now I'm greeted with the dreaded Access Denied message.

The resolution is to restore the default values for the admin user into the user_auth_realm table:

update user_auth_realm (realm_id,user_id) values (1,1),(2,1),(3,1),(4,1),(5,1),(6,1),(7,1),(8,1),(9,1),(10,1),(11,1),(12,1),(13,1),(14,1),(15,1),(16,1),(17,1);

[atxdba]

I was running into this problem. It wasn't a permissions issue in my case though but was a session issue. The VM i installed this on only had a couple gigs allocated to /var it filled that up over the weekend writing the rrd data. The php session files simply could not be created then. Freeing up space fixed the issue for me