Thanks for testing Jeff ! I've updated the internal version of the doc. Before pushing the change to cisco.com, i haven't noticed any difference in the CLI you mention here and the one in the doc, so I suppose nothing changed in the commands between openssl 0.9.8 and 1.1 ? ... View more

Hi, The 1728 seems like a poor choice for 12 meters high ceilings. It is omnidirection from a horizontal perspective but on the vertical level, it particularly radiates at 90 degrees. That means coverage 12 meters under the antenna will be poor. The other antenna you mention has slightly lower gain but that is because it radiates a bit more under it. http://www.cisco.com/c/en/us/td/docs/wireless/antenna/installation/guide/ant1728.html   About if you can use MIMO antenna with 1242, to be honest I don't know what the exact effects will be as I'm not enough into the design phase of wireless to answer that. In the lab, for sure it works, but maybe it has poorer performance than a regular diversity antenna, I don't know. You can find both yes and no answers to this on the internet so hard to say. ... View more

That can be many different things. However, legitimate scenarios are if the client hits another ISE portal than the ISE he authenticated with. Typically people would configure their CWA authorization result with a static ip/hostname instead of the default automatic setting and then you cannot be sure that the portal the client is redirected to is the ISE the client authenticated with. By having the automatic redirection URL pointing to the FQDN of the ISE the client authenticated with, this problem does not happen. The same can then also occur in case of load balancers.   Another case is if you force the discovery host of the nac agent, then the same problem will happen for posture. Posture will only work if it automatically discovers the ISE that authenticated its radius session.   Weirder cases can happen if there is some radius mess. For example, if you have a central webauth scenario with a foreign-anchor WLC scenario and both controllers are configured for accounting, then they will both send a different session id in their accounting packets and the client session might be terminated as soon as it started. Workaround there is to only enable accounting on one WLC or to turn it off completely.   those are common gotchas. Like I said, it can be more complex and less legitimate, but that would need severe TAC troubleshooting to pinpoint further ... View more

Hi.   1) It is not "ISE loses the credentials and asks for web portal again". Once a user is authenticated, it is authenticated as long as it stays connected. Possibilities are : -You are returning a session timeout (attribute radius 27) in the authz profile of the user. Therefore user has to reauthenticate after X seconds. But you would see a pattern, then. -Over wireless, many clients are not capable of doing fast roaming (smartphones is the biggest example) and will therefore reauthenticate with dot1x everytime they roam. A small coverage hole would be enough for the cached credentials to disappear and web portal to show up again -Over wired, this cannot really occur but the idea is that it's probably the switch resetting the connection and contacting ISE again. The idea to troubleshoot this is to monitor the access device (WLC/switch) and check if the port goes up/down, if the MAB session gets reset or something and why.   2) The captive bypass issue is that Apple devices will probe apple.com website to check if there is internet connectivity. If they can reach it, then fine, if they sense that they are redirected, they open a small window pop up with the login portal. The problem (and I still cannot understand why) is that this is not Safari, it's some nameless feature-less browser that doesn't work properly. By enabling the captive bypass feature, the WLC intercepts the requests to the Apple testpage and replies with HTTP OK. The apple device then thinks "ok I have internet connectivity" and it's up to the user to bring up a real browser to login to the portal page. It therefore does not affect non-Apple device to have the feature enabled. The problem is that in IOS 7.x, Apple decided to not just use Apple.com anymore but a whole list of testpages on different websites.   3) "whether it would solve the issue if I added certificate authentication as a secondary option, with eap-tls as the primary" => This is disturbing because EAP-TLS is a certificate authentication method. But ISE message seems to imply that the user is hitting an authnetication rule that only provides PEAP or EAP-FAST with mschap or something similar ... If you have the windows default supplicant you have close to no control on what the client will submit. I can imagine that moving from wired to wireless, the laptop would sometimes try to send password instead of certificate and/or vice-versa. Anyconnect with fixed network profiles would solve the problem elegantly. I cannot comment on your auth policies as I do not know them :-)   Regards, Nicolas ... View more

The best way is still the control at the source. Having Anyconnect deployed on domain laptops with a profile configured so that they can only join certain SSIDs.   Otherwise, you can also use profiling. Relying on mac address to prevent attackers is not secure. But if it's to prevent employee to simply pick a wrong SSID, it works. However, the trick is to create a profiling rule that will identify correctly your domain laptops. The safest way would be to add mac addresses manually to a group. Automatic ways can use the hostname of the PC sent in DHCP request to categorize it as part of the domain. You need only to play with profiling in case you have other mac addresses in the ISE db too. In a simpler setup, you can simply say that if the mac is known by ISE, it's an employee and he can connect to employee SSID only, but if mac is unknown (or known but belongs to "Registered Device" group, which means it went through BYOD), it goes to BYOD SSID only. ... View more

I think that with EAP-TLS it requires certificate binary comparison to be enabled in order for ISE to write the client mac address in the MAR cache. ... View more

Your first statement seemed to imply that the "wasmachineauthenticated" attribute would not be set to true in case of EAP-TLS machine authentication. I actually could not find clues supporting that theory nor could I find clues saying it would work. I am not sure if that attribute relies on the presence of "host/" in the username or not. That is worth testing In any case, EAP-chaining with anyconnect is much more noble ... View more

Indeed, my bad. The username in EAP-TLS will typically be the CN field of the certificate but that can be changed by the TLS profile in ISE. However, the logic stays the same. Except that to determine if it's a user or computer authentication, you can check if the user belongs to "domain computers" AD group. If it does, it's a valid machine authentication :-) ... View more

MAR is not exactly that. MAR is a cache on ISE where ISE remembers that a given mac address has machine authenticated before.   What you could do is have an authorization rule that permits access on a machine authentication (i.e. username starting with host/) and gives access to AD servers only. Another rules that says if a user authentication fails, but the computer "wasmachineauthenticated==true", then we still permit access and give access to AD servers only. On a user authentication succeeding, you give full access.   This way you don't really need regular reboots or have timeouts of any sorts. ... View more

Licenses are consumed as soon as a device authenticates. So if your ISE is profiling whole subnets, that will not really matter until those devices actually authenticates. If an unknown device authenticate with 802.1x, it consumes a base license. If a device with profiled information authenticates, then it consumes an advanced (or Plus) license. ... View more