ACS dialin problem

[Hubert Mayr-Kneilling]

Hello,

we use ACS 3.2 to validate users logging into routers and switches against a windows AD database. This works perfect.

But when validating Dial-IN Users we see a record in the "Failed Attempts" Log stating: "Auth type not supported by External DB".

In the detailed service log file (Detail:Full) there is no information about this request.

If the same user logs into the Dial-In Router by telnet, the user is authenticated againts the AD, and I find this informations in the detailed log file.

Whats going wrong.??

[Richard Burts]

It sounds like the router may be authenticating dial in users differently from telnet users. Perhaps if you post the config from the router it would help us figure out what is happening.

HTH

Rick

[Hubert Mayr-Kneilling]

Hi,

attached please find the config for the dial-in router. But I assume thats not the problem, becuase dial-in works fine with a user local defined by ACS.

regards

Hubert

[Richard Burts]

Hubert

Thanks for posting the config.

My guess is that the problem is caused by the ppp authentication chap which is configured for your dial users. Obviously it would not apply to telnet users. My experience at a customer site where I helped them do a lot of dial-in was that chap works when the router is talking directly to the device which will do the authenticating but did not work when the router talked to ACS which then sent the authentication request to some external authentication service. I believe the problem reflects the three way exchange of chap: challenge; response; validate/no validate. At this customer site we specified pap as the authentication and it worked fine.

So my suggestion to you is to change chap to pap and see what happens.

HTH

Rick

[pvanvuuren]

I must stress that I would use radius as the the preferred protocol for ppp authentication. Consider using radius for more visibality in authentication and authorisation control. Callback will work better with this config: "ppp callback permit."

I do agree that you should add PAP , since Windows based dailins use this authentication type PAP as default. Thus, I suggest you change your virtual-template to : ppp authentication pap chap ms-chap.

Regards

P

[Hubert Mayr-Kneilling]

Hi all,

thanks for all these hints. Unfortunatly the system is unavailable for me the next week, so I will not be able to test. But I will try your suggestions as soon as possible and keep you informed.

I still wonder what should be the difference between CHAP and PAP in authentication when using an external database I have no problems with the posted configuration to authenticate and authorize users locally defined on the router and users locally defined on ACS.

But I stick at nothing to investigate on the mystery of IOS.

regards

Hubert

[Richard Burts]

I referred to the difference in my previous post. Let me try to explain it here slightly differently. In my explanation it is important to be clear about what is doing the authenticating. Even though the router will send the authentication request to ACS, the authentication processing is not in ACS but is in AD.

CHAP is frequently considered more secure than PAP, especially since with CHAP the ID and password are not transmitted over the media while PAP does transmit the ID and password. But in the dial-in environment PAP is the better authentication.

With PAP the authentication transaction is fairly simple: prompt for authentication data (user ID and password), then send the authentication data to the authentication process. The authentication process evaluates the authentication data and send an accept or a deny. This transaction fits very well in the message flow through ACS to AD.

With CHAP the authentication transaction is more complex: it starts with the request to authenticate, then the authenticating process generates a challenge, the challenge is sent to the requesting station, the requesting station does a calculation using the challenge data and the user ID and password to generate a response. The response (which does not contain the ID or password) is sent to the authenticating process. The authenticating process evaluates the response and generates an accept or a deny. The major difficulty would be how would you get AD to generate the challenge?

For the dial-in environment PAP is better than CHAP.

HTH

Rick

[Hubert Mayr-Kneilling]

Hi all,

command "ppp authentication pap chap ms-chap" was the solution to the problem.

Clients now authenticate with PAP and are authenticated against the AD.

Thanks a lot for your help.

But there's still one small problem:

ACS reports a problem in "Failed Attempts" saying "Authorization failure: Service denied: service ppp protocol ccp."

This is obviously compression control protocol and we do not get compression any more on the dial-in lines.

I already configured ACS to allow ppp/ccp on group/user level (done this via interface configuration/Tacacs+/New Services). But as soon as this new service is activated on group level, no more connection is established. Dial-In Users hang and get timeouts on ppp response.