My lobby ambassador users uses NPS (RADIUS) authentication of logon in PI 1.3. However they cannot see any changes (i.e. profile name, disclaimer, logo image etc) I've made in the local lobby ambassador user profile. This is because (I guess) the template for NPS authenticated users and template for locally authenticated users are different. Also in attempt to save changes of profile of the local user I see message "NCS is currently set up to use remote authentication. Any changes to this account will only affect this local account."
My question how to change the default settings for lobby ambassador user with NPS (RADIUS) authentication?
Thank you in advance,
No. Here is the Cisco's answer:
Thanks for opening your service request on Cisco.com. So you want to know how to add Lobby Ambassador defaults via authorization attributes passed down from an external authentication/authorization server like Cisco Secure ACS to Prime Infrastructure 126.96.36.199.
Unfortunately, at this time, that isn't possible. It's not a bug, since external authentication and authorization of Lobby Ambassadors is working as designed; it's just that the design hasn't gone far enough into enabling Lobby Ambassador defaults to be passed as authorization attributes. Changes to the design of Cisco products are driven by the sales organization. I would strongly suggest that you contact your Cisco SE, Cisco account team or Cisco authorized wireless reseller, and let them know you'd like to see this feature included in future versions of Prime Infrastructure.
The workaround for getting Lobby Ambassador defaults to be pre-populated is to create a local user on Prime Infrastructure with the same username as what the Lobby Ambassador already has on the authentication infrastructure. When the Lobby Ambassador logs in, the authentication server will authenticate the user (verify they are who they claim to be) and authorize them (specify what they are allowed to do) as a Lobby Ambassador for Prime Infrastructure. That local account on Prime Infrastructure--that has the Lobby Ambassador defaults already configured--will add that extra authorization to the session.
User Louise has an account in Active Directory with password Cisco123, and is in an ACS group where she is designated as a Lobby Ambassador in Prime Infrastructure. There is also a user account Louise on Prime Infrastructure (with password itdoesntmatter) that has the Advanced tab completed so that any account Louise creates can only be applied to a controller list (or specific controllers on the controller list) and a guest account disclaimer of "...you're on your own..." and the defaults editable box unchecked. When Louise opens a browser to Prime Infrastructure, she logs in with username Louise, password Cisco123. She can create guest user accounts, but can only apply them to the controllers that appear on the list (and the list can be previously checked with the controllers that network admin deems appropriate) and she cannot write her own disclaimer.
Authentication won't be done with these local accounts, it will be done by the external server. The external server will also provide something of a "phase 1" authorization, defining the user as a member of the Lobby Ambassador group. The local account entry would provide a "phase 2" authorization, which would cover the items from the Lobby Ambassador Defaults Tab. In implementing this workaround, it's important that the account name in Prime Infrastructure be configured to exactly what the account on the external server is, be it Dmitry.Blinov, SGS\Dmitry.Blinov, US:SGS\dblinov, etc., so that when the session gets passed back from the external server, Prime Infrastructure has something to match on.
I personally agree with those who feel that this is not an elegant solution, nor does it scale well for organizations that have lots of Lobby Ambassadors. Unfortunately, it's the state of where Prime Infrastructure (and NCS and NCS, for that matter) is today. Input from your account team will drive a better solution.
Ok, what a pity
But thanks’ for the quick response.
That's not a solution to have the accounts also set up in Prime. But ok I understand it's a workaround.
But unfortunately that doesn’t work when you authenticate a user in a different AD domain through NPS, because then you must specify DOMAIN\username and then Prime doesn't recognize it as the same user as the local.
But then I now I don't have to spend more days on finding a solution. It's just to face the fact that the only solution is to use local accounts in Prime instead of Radius authentication. But what a pain in the ass.
I really hope it will be a feature in Prime Infrastructure 2.0. Because even that Cisco doesn’t see it as a bug, I as a customer definitely see it as a bug. And I can’t understand how they have missed that in such a complex tool as Prime.
I completely agree that suggested workaround method is not convenient. The design of Prime is really lame.
I asked the local representative to push Cisco but they doesn't believe in success. Maybe your message to Cisco (like I did it already) will helps them to understand end-users requirements...
As for me I use NPS auth of a lot lobby users and each of them see default page and give the default paper to the guests with Cisco logo. Some kind of the advertising of Cisco, isn't it?
2 years have passed, Prime Infrastructure 2.2 is the current version. Any progress on that topic? I can't image that it is that hard to define some kind of lobby ambassador profiles within PI whose name is handed over via tacacs or radius attribute.
Hi Dimitry, hi @all,
are there any new information from cisco according to this task?
My customer like to have the same solution.
Because they like to add many LobbyAmbassadors to the System and they dont like to maintain them in two different Systems.
Thanks for your efforts.
Looks like Cisco are pushing Prime owners down the Cisco NAC Guest Server route, now found in Cisco ISE. That will offer the ability to lock down lobby ambassador account settings to say 24 hours and auto-generate a password. It's a shame they don't enable it on Prime as it's a simple feature to deliver ...
I have been trying to secure my lobby ambassador accounts as well. While I haven't yet found a great solution, I have managed to prevent Lobby Ambassadors from changing the default settings.
We have setup NCS (currently 188.8.131.52) to use TACACS+ authentication for Lobby Admin. When the users authenticate to NCS, they use their AD login info to sign in. However, if I create a local account with the same username as their AD, NCS sees the login as local. That username now has to follow the rules I set on their local account.
So far the only problem that has solved for me is the Never Expire guest accounts. Once I figure out a way to apply the Password Requirements to these accounts, I'll be at least happier.
For the record, it does not appear that this gets any better with Prime 2.0.