remote authentication via 802.1x

[tedauction]

Hello I am looking at setting up 802.1x port based authentication with Cisco switches and Active Directory.

I am planning on using either:

- machine authentication via AD computer accounts using the standard 'computer name / SID' authentication method.

or

- computer based certificate authentication via AD using client-side certificates mapped to the AD computer account.

I understand the first option is commonly used, but has anyone ever used the second approach ?

Can anyone comment on the pros and cons of either ?

Thank you kindly.

[Francesco Molino · Accepted solution]

Hi

To be honest with you, I never use Machine authentication as it's based on computer name that's not really reliable.

I always use User/Password, Machine certificates (AD) and User certificates.

I'm combining Machine certificates with User/Password or User certificates to be more secure and to allow some traffic based on the 2 success authentications.

Anyway, don't forget to enable MAB (Mac Address) on ports that can host devices not compatible with Certificates and/or User/Password like some printers...

I've done some years ago a Pro/Con of User/Password vs Certificates (It was for a specific request but that can help):

Username/Password:
• Pro: Easy to deploy - just takes some code and a secure data store. Depending on the security policy, can autogenerate passwords or force new users to create them.
• Pro: Easy to administrate - password resets can (for some security policies) be done with automated tools
• Con: For good security, passwords should be reset early and often. User's forgetting or failing to change passwords is either a security risk or a usability hassle.
• Con: Good passwords can be hard to remember, which leads to the issues of users reusing passwords or writing them down.
• Con: Password data stores are a weak point - if an intruder gets the password store, he gets the motherload.
• Con: All parts of password transmission can lead to exposure - websites that store passwords locally for ease of use, internal server components that transmit in the clear, log files in COTS products that store passwords in the clear. With the secret being part of the transmission, you're only as strong as your weakest link - it takes serious effort to prevent exposure and the requirement is on both the user and the system developer.
Certificates:
• Pro: Doesn't require the transmission of the secret. A proof of private key contains no secret information - mitigates all sorts of storage/trasmission weak points.
• Pro: Issued by a trusted party (the CA) which allows for a centralized management system for status across multiple applications. If a cert goes bad, it can get revoked. Fixing a password breakin must be done separately for each system, unless a shared ID is used.
• Pro: Non-repudiation case is stronger - in most password systems, the way the user is initially authenticated prior to account creation is pretty weak and the password reset mechanisms can offer another factor of plausible deniability. With many forms of certificate issuance, it's far harder for a user to say it wasn't them. Caveat - you're still only as good as your CA's issuance policies.
• Pro: Serves more purposes than just authentication - can provide integrity and confidendiality as well.
• Con: Still requires a password/pin - almost any private key pair storage mechanism is then unlocked with a PIN. SmartCards can have tamper protection and lockout capabilities to prevent brute force, but that doesn't fix the fact the user wrote his PIN on a sticky note next to the computer where the card is docked. Sometimes password issues reappear on a smaller scale with PKI.
• Con: Complexity of infrastructure - setting up a PKI is no easy task and generally so expensive in both deployment and maintenance that it can only be used for large/expensive systems.
• Con: Certificate Status reporting and updates are not easy - revoking a user credential that has become corrupted is onerous due to the size and complexity of the infrastructure. Usually a CA generates a CRL that may or may not be provisioned within an OCSP server. Then every application should check every login for the CRL or OCSP status. This introduces a variety of time delays into the system between the time a PKI credential is reported as compromised and the time when the systems that rely on that credential actually start denying access. The speed of status update can be accelerated - but at a greater system complexity cost.

Cisco Switch configuration would looks like:

aaa new-model
!
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization auth-proxy default group radius
aaa accounting dot1x default start-stop group radius
!
dot1x system-auth-control
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 10 tries 3
!
radius server Radius_Sever_Name
address ipv4 x.x.x.x auth-port 1812 acct-port 1813 (For some servers it will be auth-port 1645 and acct-port 1646)
key "Radius_Key_to_type_in"
!
interface GigabitEthernetx/x/x
description *** User/Phone port Template ***
switchport access vlan XXX
switchport mode access
switchport voice vlan XXX
authentication event fail action next-method
authentication event server dead action authorize vlan XXX ==> a Vlan to assign to the port in case of Radius Server connection issue (not responding to the switch requests)
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication open ==> Useful when deploying dot1x as open method will allow all required protocol like DHCP, TFTP,… In Close mode, you'll need an ACL allowing required protocols.
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate 600
authentication violation restrict
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout tx-period 5
!

You have a Cisco guide with recommendations/Best practices for dot1x deployment:

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.pdf

Then you need to configure your radius server that could be handled by Cisco ISE, Cisco ACS, Windows NPS,... (and some others).

Thanks.

Hope I've answered your question

PS: Please don't forget to rate and mark as correct answer if this answered your question

[tedauction]

Hello Franceso, thanks for the excellent information.

Can I just ask when you say "...I never use Machine authentication as it's based on computer name that's not really reliable".

How is it unrealiable? I understand it also uses an SID password in association with the computer name.

Thank you.

[Francesco Molino]

What I says is that only machine authentication couldn't be a trusted method to assign a policy on a port. I mean, if we take an example of a shared machine, with any user credential you don't know who's connecting and then can't push specific acl based on the user identity.

I'm always combining a machine "authentication" (whatever computer name or certificate) with a user "authentication".

Machine authentication will get a global ACL allowing some global (non critical) services and when user authentication occurs then ACL is more specific to this user (based on his/her AD group membership, service where he/she works,...)

In addition to that, sometimes (for customers who wants), I use SGT (Security Group Tags).

thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question

[tedauction]

additionally, wouldn't another con of the 'machine certitficate' or 'user certificate' method be that if anyone else got on to that computer, they could simply copy the certs inc. private key and install on another computer ?

Isn't that an extremely easy method of spoofing a computer's or user's identification ?

or is that precisely the reason why you use 'username/password' in addition to machine or user certificates ?

[Francesco Molino]

If you can export a certificate with its private-key doesn't matter machine or user certificate, this certificate is compromised. But if you don't allow the export of this certificate it will be bit more secure, isn't it?

But as always, it is the same of user/password or other methods. 100% of security isn't possible there will be always a breach somewhere. The goal is to secure as maximum as you can.

That's why, as I said, I'm using quite often, 2 steps authentication.

[tedauction]

Is it true that machine authentication uses more than just the computer name i.e. does it use the SID as a form of password when authenticating to a RADIUS server ?

[Francesco Molino]

Yes it's true. SID is used to authenticate the machine on Windows AD

[Georg Pauwen]

Hello,

I only know of client certificate authentication in conjunction with an AAA/RADIUS server. Would adding the RADIUS server to the Windows server work ?

[Francesco Molino]

Hi.

I'm not sure I understand your question. Yes it will works if you take NPS service as Radius in a windows server