It seems that none of the Flash parts (agent panel, conference manager, manager interface) are working but screen pops are... My /etc/flashpolicy.xml has in it...
But I can't seem to connect... I keep getting "Connect attempt from 'xx.xx.xx.xx' unable to authenticate" errors when I try to use any of the flash parts. My manager.conf has...
permit=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
I've even added the user (the "usr" URL parameter and the "agent" flash parameter) into the manager.conf (also tried users.conf) with absolutely no success. I set the "secret" to the same password as the web portal in both users.conf and manager.conf scenarios.
I also tried changing the "internal" password to the password that's set in Thirdlane, but that just results in Thirdlane not being able to do much of anything.
I have literally run out of ideas. Can anyone help me?
Sorry to open an old thread,
Sorry to open an old thread, but I cannot get the Agent Panel to display anything but a blank table with login all/logout, etc on it. No matter what I try it is empty. I installed thirdlane from the ISO. Anything else I should do?
Update:
In CLI I get the following message when I try to access the Agent Panel:
[2012-03-28 23:29:31] NOTICE[21540]: manager.c:2262 authenticate: x.x.x.x failed to pass IP ACL as 'manager'
[2012-03-28 23:29:31] NOTICE[21540]: manager.c:2296 authenticate: x.x.x.x failed to authenticate as 'manager'
x.x.x.x obviously is my IP address.
Check your manager.conf file.
Check your manager.conf file. You may need to add an entry for you ipaddress.
Cheers,
Chris
So I would need to add every
So I would need to add every single persons IP address to be able to use the Agent Panel?
That doesn't really make any
That doesn't really make any sense as most users logging in are going to have Dynamic IP addresses.
you NEVER want the
you NEVER want the manager.conf available to internet. This is why this sort of application is highly frowned upon for MTE. Do you realize the AMI is a plain-text communication? Do you realize that anyone capturing packets can learn the username/password to gain access to the AMI if you have granted access from the same netblock they attempt to connect from? Once someone can authenticate against the AMI they can do a show dialplan and discover which context they need to use to place outbound calls. At that point they can use the originate command to bridge a call from one unauthenticated IP such as their pbx, to your provider via your dialplan. Instant free international calls or local access and instant expensive bill for you. If you are hosting the PBX offsite for a customer you should look into some sort of VPN tunnel to another piece of equipment so that you can limit your access to only those IPs. Otherwise the lessen someone would be all to willing to teach you can be quite expensive. I have had other clients tell me it was close to 14k USD for an exploit that only lasted a couple of days.
Ugh... Flashpolicy.xml has...
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" to-ports="*" />