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 1.3.0.20.
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.
For example:
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.
Sincerely,
