Identity and Policy Control
Reply
Contributor
l0stb0y
Posts: 21
Registered: ‎09-15-2008
0
Accepted Solution

Using the JUAC tab of Profiles in the Odyssey Client to pass Realm and Role

I was wondering if anyone had any suggestions for my current issue. My plan is to create 2 unique odyssey installers for the two domains we have in our company. I would like to prepopulate the realms and roles for each domain but it doesn't appear to be passing through from the JUAC tab. I also read that you can send the realm by adding a suffix of @realm to the end of the username, but I want odyssey to pull the username from the logged on user and can't figure out how I would combine the two if it is possible? As it stands, I have all wireless clients (both domains) coming from the same wireless controller so I only have one radius client/location group defined. They all hit the same sign-in policy and it has separate realms for each. The problem I'm having with this scenario is that it is running the host checking rules defined for both domains and one of the checks fails each time since they are domain specific. I expected to be prompted with a realm list because there is more than one but it is not happening. After one host check passes and the other one fails the client does find itself in the right realm, but this does not seem the correct way to do this. Any thoughts on how to successfully have the odyssey client send the realm and role and the logged on username would be greatly appreciated.

 

Thanks,

Rob

Contributor
l0stb0y
Posts: 21
Registered: ‎09-15-2008
0

Re: Using the JUAC tab of Profiles in the Odyssey Client to pass Realm and Role

I ended up opening a case with Juniper and the engineer escalated it to development. It turns out that having two different realms sharing the same sign-in policy results in all realm host checking policies running. It would pass host checker for the realm I was connecting from and then fail for the other. The predefined realm in the Odyssey client was actually passing through correctly, but the problem was host checker was running for both the predefined realm and the other one too. To the surprise of the engineer and myself, development responded that this is operating as it should. The engineer suggested moving host checking to the role level. I did this and now it works perfect and a wireless client comes in with the predefined realm and then gets directed to the role where host checking occurs before the client gets an IP. The other way he suggested to differentiate them would be to use EAP-TTLS for one realm and EAP-PEAP for the other. Since we only have one role assigned per realm, role host checking worked better for us.
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.