Security

Here is the TL;DR version:

 

We are trying to move from Active Directory, to LDAP as a primary 802.1X user authenitcation source. We are doing this for two reasons:

 

1. Simplify our infrastucture-- we're already using LDAP for authorization, just not for authentication
2. Minimize outages-- our AD infrastructure has proven to be much less stable than our LDAP infrastructure

One of the things this requires us to do is support more than just EAP-PEAP/EAP-MSCHAPv2. However, Windows 7 without a third party suplicant, doesn't support any other protocol. So that means we will need to support Active Directory with MSCHAPv2 and LDAP with other protocols at the same time. At least until we can upgrade our large Windows 7 base to Windows 10 (a four year cycle for us).

 

My questions to the community is: how might one do this entirely within the logic of ClearPass without needing to do end user/device reconfigurations? And, looking at what we've been able to proof-of-concept below, what are some possible risks our ideas are introducing? (see below)

 

End TL;DR.

 

Currently we have one service in ClearPass for authenticating users on wireless within our domain. It uses Active Directory via LDAP as its primary authenitcation source in conjunction with Active Directory domain services. The only authentication protocols we support currently are EAP-PEAP with EAP-MSCHAPv2. We also use group memberships from our LDAP infrastrucure to authorize users and define ClearPass roles. The two directory requirement is purely an "us" problem, having to do with where specific pieces of data reside in our directory infrastructures.

 

In order to move to a purely LDAP setup, we came up with a couple ideas:

1. Create a new LDAP-only service and a new SSID and only allow users on the new SSID to use the new service
2. Create a new LDAP-only service and some how use other service rules to limit which types of clients could use this new service-- e.g. Windows clients need to use Active Directory, all others can use the LDAP-only service.

We decided not to go with solution #1 because we use "eduroam" as our primary SSID so creating a new SSID breaks the continuty our users currently have when roaming to other eduroam instituations. Additioanlly our wireless engineer is generally opposed to adding any new SSIDs.

 

In attempting #2 we found inherent issues trying to use service rules to delinate client operating systems and/or authentication protocols.

 

Regarding the former (the client type/operating system), we could use DHCP profiling to determine the operating system, and then attempt to send all windows comptuers to the AD authentication service, and all others to the LDAP authentication service. My problem with this profiling solution that its like a big blunt blind hammer that give us no option to move Windows 10 system to pure LDAP authentication nor move windows 7 systems to a supplicant that supports the LDAP compatible protocols.

Regarding the latter (the protocols), I do not claim to understand the details of an 802.1X authentication, so I fully admit I speak from high level experience and not from deep technical knoweldge. But what I found is that the service rules cannot be used to determine which authentication protocols are being used by a client, because at the time of service catagorization, the authentication protocols have not yet been negotiated. However it does seem that at the point of enforcement policy evaluation, authentication protocols have been negotiated.

 

So, we came up with the following somewhat convoluted solution:

 

• Create two services, for demonstration I'll call one AD-Service, and the other LDAP-Service, in that service order.
• Add all supported auth methods to both services, in our case EAP-PEAP/MSCHAPv2, EAP-PEAP/EAP-GTC, EAP-TTLS/EAP-GTC, EAP-TTLS/PAP.
• Create a new attribute in the endpoints attribute dictionary called "Inner Auth Method" or some such.
• Create a new enforcement profile that sets the above attribute to %{Authentication:InnerMethod}
• Add a primary (#1) condition to the LDAP-Service's enforcement policy, if the client's inner method is MSCHAPv2, apply the above profile, apply a generic radius profile, and CoA.
• Add a primary condition to the AD-Service enforcement policy, if the client's inner method is NOT MSCHAPv2, apply the above mentioned profile, apply a generic radius profile, and CoA.
• Add a service rule to the AD-Service that requires the "Inner Auth Method" attribute be set to MSCHAPv2.

The result is that the AD-Service is passed over the first time a client auths, then if MSCHAPv2 is used within the LDAP-Service, the endpoint is tagged, its CoA'd and next time around it hits the AD-Service successfully.  If MSCHAPv2 is not used on the LDAP-Service, enforcement, and profiling continue as usual.

Alternatively, if an MSCHAPv2 tagged endpoint is later reconfigured to use an LDAP compatible authentication method, it will hit the AD-Service, update its "Inner auth method" attribute, CoA, and hit the LDAP-Service next time around.

 

This seems to work pretty well in our test environment.  However it seems to me it will add some overhead.  My question is how much, that is, too much?

 

I'd really like to hear other ideas and feeback on this idea.

Writing auth method to the database is not a good idea as it can change at
any time. Endpoint attributes should be from authorization. Also, the
combination of consistently writing the data to the database and CoAing
clients could cause performance issues.



How are you measuring the performance of AD? What were the issues that were
happening?



These days, the only realistic two options are EAP-PEAP/MSCHAPv2 and
EAP-TLS. Was EAP-TLS explored? That is the golden standard and is the second
most supported EAP type by clients (behind PEAP).



EAP methods are configured locally on the client so if you are changing the
EAP method that you'd like to use, you need to touch the clients.



Also, Windows clients can use LDAP or AD. It really depends on what you're
trying to do and what AD features you're trying to use.

Hey Tim-

It's Aaron from Boston College (that should give you some more context).

Also glad to hear you joined Aruba/HP officially. It's a big win for
all of Aruba's customers.

> Writing auth method to the database is not a good idea as it can change at
> any time. Endpoint attributes should be from authorization. Also, the
> combination of consistently writing the data to the database and CoAing
> clients could cause performance issues.

In this setup we are writing the auth method only when it changes, so
it will always update if the auth method changes. But for most clients
it will only be written once-- not every auth.

The CoA will only happen the first time a client that demands MSCHAPv2
connects. If it continues to use MSCHAPv2 it won't need to be written
again. Same with a client that changes from MSCHAPv2 to another
method, only on the auth when it changes. Not every auth.

Most clients on campus support non MSCHAPv2 auth methods so none of
this will apply to them, only our windows base.



> How are you measuring the performance of AD? What were the issues that were
> happening?

We had many different problems with AD. Some of them you were privy to
when you helped us work through them. Measuring performance of
AD-LDAP lookups is done via the RADIUS logs. But those are only half
the equation. The MSCHAP portion of the authentication relies on DNS
SRV records and doesn't load balance well. Depending on AD also means
we're dependent on another service and the team that runs it. So
regardless of the technical problems, from a political perspective,
there is robustness gained by not relying on more than one group for
authentication and authorization.


> These days, the only realistic two options are EAP-PEAP/MSCHAPv2 and
> EAP-TLS. Was EAP-TLS explored? That is the golden standard and is the second
> most supported EAP type by clients (behind PEAP).

EAP-TLS is a pretty financially expensive solution via Aruba OnBoard.
We do use it in labs where user auth isn't viable and in some other
special cases. Moving completely to EAP-TLS isn't reasonable for us as
it would require touching all 20,000 802.1X end user devices.

EAP-GTC is widely supported by all OS versions except Windows 7.


> EAP methods are configured locally on the client so if you are changing the
> EAP method that you'd like to use, you need to touch the clients.

True, but most clients (other than Windows) negotiate this
automatically and don't require manual intervention. For instance
iPhones and OS X (the majority of our user endpoints) will happily
switch between EAP-MSCHAPv2 and EAP-GTC depending on what the service
offers, without reconfiguration or even prompting the user for a
password.


> Also, Windows clients can use LDAP or AD. It really depends on what you're
> trying to do and what AD features you're trying to use.

We've been down this road before. Our LDAP does not store plain text
or one-way hashed passwords as AD does. We cannot use LDAP with
Windows 7 clients.

aaron