There's a mobile version of our website.
i see there is an option to "allow password change" or "force password change" for guest roles in the NGS. But when i created a guest account using this guest role, after webauthentication , there is no prompt to change password. Is this the intended behaviour or is there anything else that i need to configure. Looking at it, i am not sure how the NGS would allow a "guest user" to really overwrite the password by allowing password change. ? is that not a security risk as well for the NGS ? my setup has 5508 anchor controller and NGS communicating via RADIUS.
From what I know, that will only work if you use the NGS as a radius and use it to store guest credentials.
Sent from my iPhone
Also this only works if you then use the NGS as your hotspot. The password change functionality does not translate across to the anchor controller. This puzzled us for some time.
The functions involved are AJAX based and there appears to be no API capability for such guest functions in order to remotley access or control them.
We originally had web-auth on our 5508 anchor with the NGS as a RADIUS, but in order to take advantage of the full NGS capability regarding giving guests the ability to change passwords we had to migrate the web-auth page from the anchor-controller on to the NGS itself (using the inbuilt Hotspot function)
If you go down a similar road to us, I would advise either moving your NGS into the DMZ with the anchor controller, or NAT'ing it to a public address to facilitate importing a valid public SSL certificate (unfortunatley this is poorly documented on the Cisco website but I have other posts that talk about this within the community) --> https://supportforums.cisco.com/message/3548097#3548097
Hope this helps?
Probably a common question. Using NGS for hotspot web-login it should really be placed in the DMZ. This is what we are looking to do. The security guys have a problem with a device in the DMZ referencing AD on the LAN for the sponsor login.
A device that faces the DMZ and LAN should surely have two interfaces? Or is there something I am missing...
We're having to use the anchor WLC for web-auth, so losing the sigle point of reference and the password change feature.
Any thoughts appreciated. I am unable to justify the security arguement of NGS on LAN with hotspot enabled, or NGS in DMZ with AD sponsor enabled.
We had much the same issue, more around using AD for SSO for sponsors as well as using the NGS as the hotspot.
The way around it for us was to have the NGS sit on the inside of the network, with a FQDN (fully qualified domain name) that had a public IP address to the outside world, but also a CNAME to an internal address on the inside of the network and ran NAT on our firewall at the DMZ to link the public and private IP together.
The flow looks something like this:-
Wireless Client --> (public IP: NAT'd to private IP) --> Firewall --> NGS on internal network
NGS on internal network <-- (private IP) sponsor
NGS on internal network <-- (private IP) active-directory
The reason we use a CNAME internally is so we can maintain the FQDN which is publically signed by an external CA.
This seems to work ok. Also the anchor-controller we have for guest access also has a FQDN assigned to it's virtual interface which is also publically signed by an external CA.
This stops all the security pop-ups and provides a more seemless experience to wireless clients associating with the network.
Security is taken care of by strictly controlling access to the NGS both on the anchor controller using ACL's and also on the DMZ firewall. So if traffic targetting the NGS comes in from the internet intended for the NGS from an untrusted/unknown IP range/tcp port then it will not be permitted.
Hope this makes sense?
Thanks very much ddavies,
That is the exect setup we would need to enable the NGS as a Hotspot and host it on the LAN, though not ideal.
Surely this device needs internal/external interfaces...
I appreciate the detailed response, thanks!
I entirely agree, however the NGS unfortunatley sits on a one size fits all box which whilst it has multiple physical network interfaces it services a number of different appliances not just the NGS, and the NGS is a software appliance licensed from a UK company so I doubt there's much in the works to improve this, unless anyone within Cisco would care to correct me?
Not only are you limited to just one physical interface with the software licensed to Cisco, but you are also limited to just one SSL certificate, it appears - and if you wish to run an externally signed certificate on it invariably in todays world it will have to be a 2048bit depth certificate. Which isn't supported on the NGS by default, so in order to make it work you will have to do a bit of hacking both in the CLI and the GUI to get it to work.
I remain unimpressed with the lack of documentation for those who whish to use the NGS as a hotspot, in the end we had to raise this through TAC with Cisco, perhaps your experiences may be better than ours?
Not had great experience to be honest. It's been a case of digging around. It seems to me like the hotspot functionality was an afterthought.
Oh well, they have the chance to build a device to suit this role through their hardware refresh cycle. So the Identity Services Engine will surely fix this issue through role assignment? I'm looking into it...
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion