ACS 5.1 failed to strip Username Prefix\Suffix in Peap?

[edwardzeng]

Hi,

We got the ACS 5.1 VMWare.

We try to send the username only to proxy radius after ACS strip the Prefix\Suffix realm.

But ACS 5.1 could not strip the prefix\suffix in Peap Authenticaion Method.

If we put NAS Authentication Method to PAP_ASCII then ACS can strip the prefix\Suffix@

(The conditions were all matched and we could see the ACS did send the requests to its extend proxy radius server.)

Any idea?

[Federico Lovison]

Hi,

When using PEAP, the username used for authentication is exchanged inside the TLS tunnel, so that is not the same as the RADIUS Username attribute that you use for PAP authentication.

You should be able to strip the username at the RADIUS level though: can you confirm this please?

In ACS you have two ways to interact with external RADIUS servers:

- RADIUS proxy:

In this case ACS will just proxy the RADIUS packet to  the external RADIUS server with no influence on what is inside the PEAP  tunnel.

In this way you can forward to an external traffic even for auth methods that are not specifically supported by ACS, as ACS is not "touching" these packets:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/common_scenarios.html#wp1153241

- External RADIUS ID Store:

In this case the PEAP tunnel would be terminated on the ACS itself which will use the extracted data to send a new RADIUS auth request to the external server:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.1/user/guide/users_id_stores.html#wp1181773

With the external RADIUS ID Store only some auth methods are supported:

•RADIUS PAP

•TACACS+ ASCII/PAP

•PEAP with inner EAP-GTC

•EAP-FAST with inner EAP-GTC

The reason behind this is that ACS must be able to get the username and password (and not a hash or challenge) to be used to authenticate the user against the external server.

Given this, what you see in ACS looks normal, based on how the PEAP EAP method works.

I hope this helps.

Regards,

Federico

--
If this answers your question please mark the question as "answered" and rate it, so other users can easily find it.

[edwardzeng]

Hi Federico,

Thanks for your reply.

Yes, the RADIUS level can "see" the username details.

Because I put  "RADIUS-IETF:User-Name contains @###.com " as one of the policy match condition in the Service Selection Rules.

The ACS1 did forward the user to its proxy radius base on this condition.

I tried to use the  external RADIUS ID Store, but there are no option to strip the @ realm? (Please let me know if I missed it.)

Only when you create a new Access Policy and set its Service Type as RADIUS proxy, then you can use the Username Prefix\Suffix Stripping.

So we have to use the RADIUS proxy to achieve that, but that function is not working on Peap, ( Ms-chap v2)

( The reason we need to strip the realm are our AD domain is not the same as our Internet DNS domain. )

Any suggestion?

Many thanks again.

Cheers

Ed

[Federico Lovison · Accepted solution]

Hi Ed,

The point is that although ACS can process and strip the domain name from the RADIUS Username, that is not used for the actual PEAP authentication at the external RADIUS.

The reason is that the credentials that are used for the authentication are inside the PEAP TLS tunnel, thus the ACS acting as a proxy is just forwarding this information and it has no access to this info.

Consider that the RADIUS Proxy feature works even if you forward EAP methods that are not supported by ACS, so in this case ACS is not supposed to touch what's inside the RADIUS packet.

I think in your case the only solution would be to configure the domain stripping at the external RADIUS server, that is the one that will be able to extract the credentials from the TLS tunnel and process this info.

Whether this is feasible or not depends on the features of the external RADIUS server in use, but I believe that you can't do much more on the ACS side using RADIUS.

Considering how RADIUS proxy works and the fact that you can't even use the external RADIUS ID both because you can't do the domain stripping and you can't use MSCHAPv2 based auth protocols (although this would work with PAP or EAP-GTC), you either process the PEAP username on the external server or.. you should rather use a different way to access the AD.

This would open different scenarios and may go out of the scope of this post

I hope it's clear about what ACS is doing and why the domain is not stripped by ACS on the inner credentials.

Thanks,

Fede

[edwardzeng]

Hi Fede,

Thank you kindly for your reply.

I beleive this is the answer for this topic.

We will try to find a work around for that.

Because the extenal RADIUS server is just another ACS 5.1. (We may use the 1121 with ACS 5.2 version.)

But I only find that striping function in  the RADIUS proxy settings.

I am not sure the external ACS can strip the domain or not even it terminates the TLS tunnel.

Or I miss it somewhere else?

Thank you very much again.

Cheers

Ed