NAC Guest server allow password change

Unanswered Question
Dec 25th, 2011

hi,

  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.

regards

Joe

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Scott Fella Sun, 12/25/2011 - 09:30

From what I know, that will only work if you use the NGS as a radius and use it to store guest credentials.

Thanks,

Scott Fella

Sent from my iPhone

ddavies016 Mon, 02/06/2012 - 20:09

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?

rob.simkins Thu, 03/01/2012 - 09:11

Hi there,

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.

Rob

ddavies016 Thu, 03/01/2012 - 14:22

Rob,

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?

rob.simkins Sat, 03/03/2012 - 02:39

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!

Rob

ddavies016 Sun, 03/04/2012 - 14:21

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?

rob.simkins Tue, 03/06/2012 - 07:09

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...

Actions

Login or Register to take actions

This Discussion

Posted December 25, 2011 at 9:12 AM
Stats:
Replies:7 Avg. Rating:
Views:1014 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard