WAN/internet access to ZM 1.22.3 monitors page (CentOS)

[pdown85]

Linux CentOS 4.4 (2.6.9-42.0.3.EL)
Apache 2.0.52 (CentOS) web-server
ZoneMinder 1.22.3

Setup is a LAN behind a NAT wireless-router. Linux server, multiple WinXP boxes.

Behind the router I can open the ZoneMinder page from IE on a WinXP box with no problem. Both ZM user accounts (one priv/admin account, one non-admin account) can get access with no problem and access the ZM monitors page (and the former account can create/modify/delete monitors at will).

But if I try to get access from the WAN/Internet side I have a problem.
When I click the link to the zm/zm.php location from the web-site page: I get the Apache/HTTP logon prompt (as expected as authorisation is defined in the httpd.conf) and I enter that Apache username/password combination fine: this takes me to the expected ZoneMinder user account logon screen. At this point I can get no further for either ZM user account: I get the ZM "Logging in" message and then the ZoneMinder user logon page re-displays with the input fields cleared.

Is it a router port issue? Only port 80 to allow access to the web-server is open on the router. Does ZM expect other ports to be opened?
Or is it some other configuration issue within ZM somewhere?
I think it is more likely the latter given I can get to the ZM page from the WAN via the web-page and see the ZM logon screen accept the ZM user name and password and attempt to logon.

Any ideas as to what have I missed in the configuration? Or where I'd even start to look?

TIA.

[zoneminder]

Do you get the httpd auth prompt when accessing from your LAN? I'm wondering if that is confusing it somehow.

[MJN]

I get the Apache/HTTP logon prompt (as expected as authorisation is defined in the httpd.conf) and I enter that Apache username/password combination fine: this takes me to the expected ZoneMinder user account logon screen.

Is this how you wanted/expected it to work? As you're using HTTP AUTH you can do away with the built-in ZM authentication as, if you set ZM_AUTH_TYPE to Remote then ZM will be passed the username by your client (hence doing away with the ZM login screen as it's superfluous given you've been authenticated).

Given you're still getting the built-in ZM login I'm guessing you've got ZM_AUTH_TYPE set to Built-In? If so, try it on Remote as this may well 'solve' whatever your problem might be (whilst retaining the functionality I'm guessing you're after).

Apologies if this is way off the mark... only been using ZM a week and am still in the exploration/experimental stages!!

Mathew

[pdown85]

Do you get the httpd auth prompt when accessing from your LAN? I'm wondering if that is confusing it somehow.

Thanks for the reply.

The answer to your question is no. When I access direct from the LAN for ZM I have configured httpd.conf to let the local subnet straight in with no HTTPD password prompt required to the ZM logon screen. But on WAN access the .htaccess password is asked for by httpd.conf and then ZM logging kicks in.

This has worked for me in the past for things like MRTG and Webalizer and (which of course only requires the .htaccess password) the I thought I'd persuade ZM to go the same way. But currently no-go.

I have ZM fully working in just about all other respects (after something of a struggle with a USB webcam on the Linus box - but that's another story which was all to do with the webcam and not ZM) and so I am coming to the conclusion that in fact my issue is with httpd.conf. I am wondering if perhaps httpd.conf needs to be told of the location of the MYSQL database folder in order to allow access to it. The access to the main zm folder with zm.php in it is granted in httpd.conf and so the ZM "Logging in" message can be seen (after I've got past the HTTPD password prompt dialog) but then ZM goes off to MYSQL to verify passwords but cannot get at it because httpd.conf does not allow it?

See also my response to the posting from MJN next.

[pdown85]

Is this how you wanted/expected it to work? As you're using HTTP AUTH you can do away with the built-in ZM authentication as, if you set ZM_AUTH_TYPE to Remote then ZM will be passed the username by your client (hence doing away with the ZM login screen as it's superfluous given you've been authenticated).
....
Apologies if this is way off the mark... only been using ZM a week and am still in the exploration/experimental stages!!

Thanks for the reply. I too am only using this a week or two and this is still something of a learning experience!

Yes this was how I expected/wanted it to work (see also my previous response to zoneminder).

However I have tried out your suggestion (set ZM_AUTH_TYPE to Remote) and I wonder if I have discovered a wrinkle in ZM! And as you'll see from the following description the ZM Login screen is not done away with (or at least so I found).

On access now from the Internet ... I am prompted once again for the httpd.conf password by HTTPD as expected which I successfully enter and progress beyond ....... and now the ZM logon prompt page is displayed with the username field pre-populated with the HTTPD username I just entered on the HTTPD dialog screen! If I now enter the password for that HTTPD username I get - as expected - nowhere because it is a HTTPD password and not one ZM knows anything about. If I clear the username field and enter a valid ZM username and password I still get nowhere - and the page just re-displays with the HTTPD username re-populated in the user field. Finally if I clear both fields and try to enter with both blank I still get nowhere and again the page just re-displays with the HTTPD username re-populated in the user field. The interesting thing now is that in all the attempts here (with ZM_AUTH_TYPE set to Remote) the (ZM) "Logging in" message seen previously is not displayed.

So as I see it in order to gain access I'd need either

i) to set ZM_AUTH_TYPE to Built-in and disable HTTPD authentication on the folder and rely on ZM authenication - but I do not really want to do that as it could leave the server folder open on the Internet to accessing through Apache, or
ii) to set ZM_OPT_USE_AUTH to off altogether and rely on HTTPD authentication to govern access from the Internet.

In fact I have tried out ii) and it works - on entry of the HTPPD username/password I am straight in. Unfortunately the downside to this approach is that on the LAN-side there is no authentication and access is immediate without password.

Late PS: I have just read the fine print on ZM_AUTH_TYPE "The second method allows interworking with other methods such as http basic authentication which passes an independently authentication 'remote' user via http. In this case ZoneMinder would use the supplied user without additional authentication provided such a user is configured ion ZoneMinder." That, of course, I do not currently have ... so I'm off to give that a go!

[pdown85]

Late PS: I have just read the fine print on ZM_AUTH_TYPE "The second method allows interworking with other methods such as http basic authentication which passes an independently authentication 'remote' user via http. In this case ZoneMinder would use the supplied user without additional authentication provided such a user is configured ion ZoneMinder." ...

Follow up to my last posting.
With settings as follows:

• ZM_OPT_USE_AUTH = Yes
  ZM_AUTH_TYPE = Remote

Provided the HTTPD account that is authenicated against exists also as a ZM user account (it does not even have to have the same password) then this works fine.

I am wondering if perhaps httpd.conf needs to be told of the location of the MYSQL database folder in order to allow access to it. The access to the main zm folder with zm.php in it is granted in httpd.conf and so the ZM "Logging in" message can be seen (after I've got past the HTTPD password prompt dialog) but then ZM goes off to MYSQL to verify passwords but cannot get at it because httpd.conf does not allow it?
...

I was probably barking up the wrong tree there! I was using a HTTPD user account that didn't exist in the ZM database thus it wasn't found and so the authenication failed. In any case with the solution already found above this is no longer relevant.

Thanks for all assistance; it was just a question of not having read the documentation thoroughly enough. As usual!

[MJN]

We're all guilty of that!!

Is your LAN-access working fine now also? I'm intrigued as to why your LAN clients weren't being requiring authentication yet WAN clients were. That is certainly an Apache configuration issue. Or is that now sorted?

Mathew

[pdown85]

We're all guilty of that!!
Is your LAN-access working fine now also? I'm intrigued as to why your LAN clients weren't being requiring authentication yet WAN clients were. That is certainly an Apache configuration issue. Or is that now sorted?

Yes I appear to have the WAN authenicated access I need and still have controlled access on the LAN as well.

It's certainly a httpd configuration issue - and I'd be the first to say I may not be doing that the ideal way either. But it works for me.

I use virtual hosts and a specific port for LAN access; as per the httpd.conf snippet ...

Code: Select all

# 15/01/2007 add zm virtual host
# Virtual host Virtual Host5 
<VirtualHost 192.168.xxx.xxx:31nnn>
  DocumentRoot /var/www/html/zm
  ServerName myserver.org
 DirectoryIndex index.html index.htm index.shtml zm.php
 LogLevel warn
</VirtualHost>

...
...

<Directory "/var/www/html/zm/*">
 AuthUserFile /etc/httpd/conf/.htpasswd
 AuthType Basic
 AuthName "By Invitation Only"
 Require user user1 user 2
 AllowOverride AuthConfig
 Deny from all
 Allow from localhost 192.168.xxx.0/24
 Satisfy any
 Options MultiViews -Indexes  IncludesNoExec
</Directory>

If I enter the LAN IP and port on the URL I pop straight to the ZM Logon page by-passing the HTTPD authenication page.
If I enter the WAN IP (or dynamic DNS name) of my web-site on the URL and take my ZM link I get the HTTPD authenication page before progressing to the ZM Logon page which, now that I have Remote authenication, I sail straight past into ZM.
There are some wrinkles in terms of exactly what access, and in what circumstances that access, is granted that I am currently still working through! For example, if I enter the WAN IP (or dynamic DNS name) and port on the URL it stalls! But I am protected - as far as I can see - from the WAN and I have sufficient control for my purposes over the LAN.

[MJN]

Okay, I see.

Given you now know that with ZM set to remote authentication your HTTP authentication credentials get sent right through you might as well use HTTP AUTH for WAN and LAN access now? It'd certainly minimise the potential for future 'gotchas' to creep in which give rise to problems only affect LAN access, and not WAN (or vice versa).

I'm thinking in particular that as you've told ZM that you're using remote authentication you're actually not doing so when accessing from the LAN.

I can't think of any reason why not/ to use the same (HTTP AUTH) authentication for LAN and WAN access.

Mathew

[pdown85]

Okay, I see.
...
I'm thinking in particular that as you've told ZM that you're using remote authentication you're actually not doing so when accessing from the LAN.

I can't think of any reason why not/ to use the same (HTTP AUTH) authentication for LAN and WAN access.

I was trying to re-use the same authentication method for ZM as for MRTG and Webalizer - except these last two apps do not have their own authentication and thus rely on HTTPD whereas ZM throws a slight spanner in the works by having, as I've discovered, it's own authenication.

In the case of all three apps I could use the same HTTPD authentication from the WAN and I'd be happy with that.

In the case of both Webalizer and MRTG I am happy for LAN access to be unauthenticated as they are read-only tools (in fact it is a positive advantage for these to be widely accessible LAN-side); but I want to exercise some control over ZM access. So in the interest of uniformity I was using the same HTTPD authenication on the LAN which meant control would be exercised at the second line of defence, the ZM logon (but that was failing which is where this thread began).

I could turn off HTTPD auth for ZM and use built-in authenication only, which would apply from both WAN and LAN. But in this case as I noted in an earlier post I have concerns that the ZM directory on the web-server would be open to unwanted attention because HTTPD authenication which is now off could not prevent it.

I am sure what I need is just some additional tweak in the httpd.conf configuration!

[MJN]

Remember your HTTP authentication (or not) can be dictated on a per-directory basis hence there's no reason why you can't use it whenever, and for whatever application/purpose, as required.

I think you'd just be best using HTTP AUTH for all ZM access (LAN or WAN) as opposed to WAN-but-not-LAN, if you see what I mean. Not least given that you've told ZM you're using remote authentication and whilst it stills seems to work in its absence (by presenting the ZM login screen) it's not really the ideal situation to be in as discussed.

Re-reading your message I think I can see where you were/are coming from - you'd already got HTTP AUTH on webaliser and had configured it such that LAN access didn't require authentication, yet WAN access did? You'd then transferred the same operating model to ZM...?

Mathew

[pdown85]

...
Re-reading your message I think I can see where you were/are coming from - you'd already got HTTP AUTH on webaliser and had configured it such that LAN access didn't require authentication, yet WAN access did? You'd then transferred the same operating model to ZM...?

In a nut-shell!