How to deploy 802.1x in a Cisco network

The monitor mode should still be enforceable on specific since it is configured as per multi auth mode and open access.  As long as it is in accordance I don't see why it may be implicated in such mixed environment.  Probably good to note specific for that building in test stage and segregate the actual enforced buildings to other ports.

For monitor mode targeted on each access port, enable open access authentication and multi-auth host-mode. Without multi-auth, the switch runs in single host mode and disable any ports with multiple devices, including phones. Monitor mode requires multi-auth host-mode to be transparent to end users.

Also       to ensure that all dynamic authorization, such as dynamic VLAN and dACL assignment, is disabled on the ACS server. Any form of dynamic authorization will impact end users and thus undermine the goal of monitor mode, which is end user transparency.


http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/TrustSec_1.99/Scenario_based_AppNote/Scenario_based_AN.html

Everyone's idea/definition of Production is a bit different. For us, that's the data center where the live/real data is and other resources like file shares, intranet servers etc are. This environment is typically locked down physically and makes wired 802.1x a bit redundant and seem unnecessary. 802.1x is not an ACL in of itself, it's an authentication mechanism for mac addresses from the host to the switch only. The only effect turning on 802.1x fully should have it the allowance or denial of access to the switch port. That can be an acl if the host is denied or placed in an incorrect vlan.
Most folks deploying wired 802.1x are doing so because they are after NAC. This makes more sense in the user networks. Unless your DC is not physically protected I'm not sure why one would put it in "production".

802.1X is an IEEE standard for media-level access control, offering the capability to permit or deny network connectivity, control VLAN access and apply traffic policy, based on user or machine identity.

Again your idea of production may be different than mine. 802.1x is good for putting unknown mac-addresses into guest vlans so you block anyone coming in from using a free port or wifi connection to access your network. It's hard to deploy in small and large scales, but once it's operating it's great to have. You will have quite a few devices to whitelist, and this can be the crux of 802.1x. Dumb devices like some printers/copiers/fax, even some other switches will need to be whitelisted in the mac tables. They can't use or don't have a supplicant, and it's possible for a guest to spoof their mac address to be the same as a printer and get on the network. Not all that likely but you should be aware.
-rich

I suppose a better question would be... what if 802.1X was configured on the ACS,
along with the radius protocol but nothing in regards to 802.1X was configured on the
Cisco switches or supplicants.  I would think users would still be able to connect to the
network.  Correct?

As I stated, I would like to provision everything in phases, So AS NOT TO PREVENT USERS
FROM CONNECTING TO THE NETWORK, just in case I screw something up.

Please remember that for now, nothing except for the ACS will be configured with 802.1X (including monitor mode).

Thanks,

Rayneedssomehelp

Monitor mode should not affect anyone at all. It just logs what is happening and what it sees. You should start with that phase in as wide an area as possible, it might help you spot your troublesome hosts. Some supplicants don't work and some programs can mess with them. We had trouble with ZoneAlarm blocking supplicants and McAfee's own supplicant not working for some reason. Monitor mode should just let everything happen like it is now.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/TrustSec_1.99/Phased_Deploy/Phased_Dep_Guide.html#wp392526
-rich

We have approx. 10,000 ports\interfaces on 400 Cisco switches.

I apologize for  making this question more complicated than what I wanted it to be, but
let me try again.
Starting from scratch.  Is it OK to deploy 802.1x on all of our equipment, EXCEPT for
othe Cisco swithces and not cause any down time?  If the answer to that question is yes, I
will then proceed to place "monitor mode" on a few switches.

I have never used radius before and I am concerned about what might or could happen if
I jack up the ACS sever by trying to enable radius on it.

Rayneedssomehelp

Get the config right on a few of them, monitor mode should not affect them at all, that guide I linked to should help if you hadn't seen it already. Read it all the way through, but it should not have a deleterious affect having some in monitor and some not. Monitor mode should give everyone a "bypass" and only log what is going on. The radius/EAP will still take place, but you are putting in a bypass that allows anyone to connect still. After you're happy with that config, begin to roll that out wider and wider.
-rich

Agree with Rich. Monitor is supposed to be "transparent" but do note that it still will get to RADIUS to perform the due checks.
There is no impact to users or endpoints of any kind: they continue to get exactly the same kind of network access that they did before you deployed TrustSec. The authorization level pre-authentication is the same as after successful authentications and failed authentications: completely open. In the background, however, the network is querying each endpoint as it connects and validating its credentials.

Let say if it become enforced or the so call low impact and high security mode, any timeout in 802.1x check will fallback to secondary authentication and it can be MAB.  There will be delays overall but I don't see inadvertent long blocking unnecessarily. We also do not want a fail open too for secure by default. Typically this happened for non 802.1x capable device as earlier shared.

After monitoring and able to establish the various device asset, over time, you may transition from a default port ACL that denies access to a few resources and permits everything else to one that permits access to specific resources, such as DHCP, DNS, TFTP for PXE, and so on, and denies everything else. Evolving the default ACL in this way allows you to incrementally add access control without inadvertently blocking important traffic.

Unless you have a specific need to support multiple data devices on a single port, configure all access ports in single host-mode for non-IP-Telephony deployments, or in multi-domain host-mode for IP telephony deployments.

So what you guys are trying to tell me is that  the only difference between having a switch port  configured with "Monitor mode" versus having that same switch port configured with
no 802.1X configs whatsoever,  is that monitor mode WILL log Radius traffic and the port
with no 802.1X configs will NOT, but, THEY WILL BOTH PASS TRAFFIC AND ALLOW THE END
USER ON THAT PORT TO CONNECT TO THE NETWORK.  Correct?

Ray

Correct. The clients will also be doing 802.1x in the background. You can specify which ports do 802.1x and which don't, and 802.1x will only affect ports that have it enabled, you will not enable it on trunk ports or switch interconnects.
-rich

Rich,

If this is the case,  I can focus on implementing Active Directory with the Radius server
someone down the road, since this will be our next big hurdle after populating the
ACS server MAC database.

Ray