I have an interesting problem. We have a third-party firewall and RAS
appliance. The appliance supports RADIUS backend authentication and we
have planned to use IAS in 2k3 to supply that service. There appears
to be a problem between the IAS box and the appliance. When users
attempt to login to the appliance, it dutifully passes the
authentication back to IAS, whose logs actually shows the users as
successfully authenticating and it issuing the access-accept. But the
response of the appliance is that the users failed to authenticate.
Upon speaking to the support team for my appliance, they seemed
interested that I was using 2k3 IAS. They told me that they had not
tried it yet but that their product worked just fine on 2k IAS. I did
not want to believe that, but I decided after some frustration to test
their claim. I set up a 2k IAS machine, authorized it in AD, and
watched it succeed where 2k3 did not. Amazed, I set off to figure out
the difference.

The problem appears to be in CHAPv2 negotiation. In the failing 2k3
scenario, the PPP daemon on the appliance will show in its debug
output:

PPP send: CHAP Challenge id(1)
PPP recv: LCP Identification id(3) len(18)
PPP send: LCP Code_Reject id(2) len(22)
PPP recv: LCP Identification id(4) len(22)
PPP send: LCP Code_Reject id(3) len(26)
PPP recv: CHAP Response id(1)
No CHAP secret found for authenticating My.UserName
RADIUS server error

whereas the successful 2000 session's debug output on the appliance
side looks like this:

PPP send: CHAP Challenge id(1)
PPP recv: LCP Identification id(4) len(18)
PPP send: LCP Code_Reject id(2) len(22)
PPP recv: LCP Identification id(5) len(22)
PPP send: LCP Code_Reject id(3) len(26)
PPP recv: CHAP Response id(1)
No CHAP secret found for authenticating My.UserName
PPP send: CHAP Success id(1) msg(<--some stuff--> )
PPP send: CBCP
MSCHAP-v2 peer authentication succeeded for My.UserName

can somebody help me hunt down what the differences might be in the
two configs which cause this? Or can somebody point me towards some
resources for interpreting LCP and CHAPv2 negotiation in PPP as
applies to RADIUS?

I have already presented this to the Microsoft managed newsgroups and
they blame the appliance vendor and the vendor blames MS. Anybody else
got any good ideas?

Thanks.

[ Post a follow-up to this message ]

Sounds like you have a mismatched shared secret
Don't feel frustrated, This is one of the hardest problems to diagnose. CHAP
doesn't use the shared secret in the chap password, therefore the server
will respond back. BUT it will have the shared secret and this would cause
the appliance to drop the session. (I don't want to get in more details on
CHAP unless you want me to do so)

To resolve this issue, reset the shared secret between the appliance and the
IAS server

HTH


--
 ========================================
=====
This posting is provided "AS IS" with no warranties, and confers no
rights.
 ========================================
=====

"SumYungGuy" <jay.winks@teksouth.com> wrote in message
news:e5798ece.0408251259.15561e11@posting.google.com...
>I have an interesting problem. We have a third-party firewall and RAS
> appliance. The appliance supports RADIUS backend authentication and we
> have planned to use IAS in 2k3 to supply that service. There appears
> to be a problem between the IAS box and the appliance. When users
> attempt to login to the appliance, it dutifully passes the
> authentication back to IAS, whose logs actually shows the users as
> successfully authenticating and it issuing the access-accept. But the
> response of the appliance is that the users failed to authenticate.
> Upon speaking to the support team for my appliance, they seemed
> interested that I was using 2k3 IAS. They told me that they had not
> tried it yet but that their product worked just fine on 2k IAS. I did
> not want to believe that, but I decided after some frustration to test
> their claim. I set up a 2k IAS machine, authorized it in AD, and
> watched it succeed where 2k3 did not. Amazed, I set off to figure out
> the difference.
>
> The problem appears to be in CHAPv2 negotiation. In the failing 2k3
> scenario, the PPP daemon on the appliance will show in its debug
> output:
>
>  PPP send: CHAP Challenge id(1)
>  PPP recv: LCP Identification id(3) len(18)
>  PPP send: LCP Code_Reject id(2) len(22)
>  PPP recv: LCP Identification id(4) len(22)
>  PPP send: LCP Code_Reject id(3) len(26)
>  PPP recv: CHAP Response id(1)
>  No CHAP secret found for authenticating My.UserName
>  RADIUS server error
>
> whereas the successful 2000 session's debug output on the appliance
> side looks like this:
>
>  PPP send: CHAP Challenge id(1)
>  PPP recv: LCP Identification id(4) len(18)
>  PPP send: LCP Code_Reject id(2) len(22)
>  PPP recv: LCP Identification id(5) len(22)
>  PPP send: LCP Code_Reject id(3) len(26)
>  PPP recv: CHAP Response id(1)
>  No CHAP secret found for authenticating My.UserName
>  PPP send: CHAP Success id(1) msg(<--some stuff--> )
>  PPP send: CBCP
>  MSCHAP-v2 peer authentication succeeded for My.UserName
>
> can somebody help me hunt down what the differences might be in the
> two configs which cause this? Or can somebody point me towards some
> resources for interpreting LCP and CHAPv2 negotiation in PPP as
> applies to RADIUS?
>
> I have already presented this to the Microsoft managed newsgroups and
> they blame the appliance vendor and the vendor blames MS. Anybody else
> got any good ideas?
>
> Thanks.

[ Post a follow-up to this message ]