About l0stb0y_

zanyterp_ · ‎09-19-2010

Glad to hear a solution was found; good luck!

MJ_ · ‎01-20-2010

I, too, am dismayed by the supposed "Solution" label on this thread. A status should be just that, a true status. With the tray icon displaying "Connecting", this is an erroneous message which needs to be fixed by Juniper.

aronow_ · ‎01-13-2010

It really depends on the security problem you are trying to solve. If you are only worried about which workstations are on your network, then you only need machine auth. If you use domain logins for all the workstations, you don't have to do user network auth as they will still require authentication to get logged into the workstation. If you want to have different vlans for users vs computers, then you'll need to do machine auth and then switch to user auth. All is configurable in the Odyssey Administrator.

l0stb0y_ · ‎09-17-2009

Thanks for the suggestion. I hadn't thought about that.

l0stb0y_ · ‎06-30-2009

I discovered my problem has nothing to do with the IC settings. When doing a packet capture of the IP phone after it authenticates you see the DHCP requests, but there are never any DHCP offers. The phone only gets a DHCP address if the Cisco switchport has authentication host-mode multi-host configured which creates a new problem for me to research elsewhere.

aronow_ · ‎01-20-2009

Rob, Glad I could help, let me know how that goes. Yeah, its a bit misleading because the section is labeled Machine Auth, and it is designed around doing 802.1x, but it can do any type of auth OAC can handle. So you should be able to add your AP statically or to an auto-scan list and have OAC try to connect at the machine auth time, even though it won't actually be doing machine auth. Basically, we will just be taking advantage of the fact that the we need OAC to associate to a network without being connected in a user context.

l0stb0y_ · ‎09-25-2008

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.

Re: Bookmark prompting for domain credentials inst...

Re: OAC client managing both wired and wireless co...

Re: OAC machine authentication without certs

Re: Best way to direct 802.1X guest VLAN to login ...

Re: IC 4500, Cisco 3560 switch, Avaya IP Phone, an...

Re: Keep Odyssey wireless connected while doing lo...

Re: Using the JUAC tab of Profiles in the Odyssey ...