Answered by:
Clients cannot authenticate using NPS RADIUS, but work with IAS RADIUS

Question
-
Hi
We are in the process of moving from Server 2003 to Server 2008 (using new hardware, so no direct upgrade). We have several different classes of device that are currently using IAS RADIUS to authenticate users. We have re-created the RADIUS clients and policies within NAP but are the clients do not authenticate. I have ensured that the NAP-compliant check box is not ticked when creating the RADIUS clients.
I have used an IAS log viewer to compare the logs of a successful (IAS 2003) authentication with an unsuccessful (NAP 2008) authentication:
They both end with Connect Request Success (which is not actually true in the second case!)
The only difference I can see is with the Class part of the logs. The IAS Class log returns:
"311 1 10.0.0.7 09/29/2008 12:50:41 7" [where 10.0.0.7 is the IP address of the RADIUS Server]
whereas the NAP Client returns:
"311 1 ::1 09/23/2008 08:31:27 18"
The "::1" part looks to me like the IPv6 shorthand version of localhost, so my question is, is NAP somehow using the IPv6 address of the server, and is this confusing the client? I have disabled the IPv6 TCP/IP protocol in Network Connections so am surprised to see it presented here.
Also, what does the final number (7 or 18) mean in the Class part of the logs?
Hoping someone can help.
Thanks in advance
Phil- Edited by Pifco19 Tuesday, September 30, 2008 10:06 AM
Monday, September 29, 2008 2:47 PM
Answers
-
Just to add, if you look at the NPS server's Security Logs, do you see any events related to the client's authentication? If you are configuring your CRP to reflect the IAS' CRP, you should make sure that you have not checked "override network policy authentication settings" in the Authentication Methods.
You should process authentications at the Network Policy layer.
Clay Seymour - MSFT- Marked as answer by Greg LindsayMicrosoft employee Tuesday, October 14, 2008 9:49 PM
Monday, October 6, 2008 4:36 PM
All replies
-
Hi Phil,
I think you mean NPS, not NAP. NAP uses NPS to evaluate health of client computers, but NPS can evaluate connection request with or without client health.
Anyway, can you please look at event viewer on NPS and tell me what policies are being matched? Please look under Custom Views\Server Roles\Network Policy and Access Services
There should be events here that tell what connection request policy and what network policy was matched. You'll find this in the event under authentication details. If access was granted this will be event 6272. If NPS denied access you will see event 6273.
I'm not familiar with what the numbers mean in the logs, but I can find this out if it helps to troubleshoot. For now, it will help to know what policies (if any) are being matched.
-GregMonday, September 29, 2008 6:56 PM -
Hi Greg
Thanks for the reply. I guess I was a bit confused by the Role being called NAP. You are correct, it is the NPS component I am having difficulty with. I have modified the thread title accordingly.
I have looked in the Event Viewer as you suggest but there are no events being recorded when I try to authenticate. The only event recorded is a periodic 4400 ("A LDAP connection with domain controller XXXXX.XXXXX.com for domain XXX is established."
The server is definately being contacted though; there are entries in the NPS log in c:\windows\system32\logfiles. I have reproduced a sanitised sample below:
X.X.X.11,username,09/30/2008,09:05:39,IAS,SERVER,4,X.X.X.11,32,netlogin,5,6046,61,5,6,8,31,SANSWITCH0,4108,X.X.X.11,4116,0,4128,SANSWITCH0,4154,Use Windows authentication for all users,4155,1,4129,DOMAIN\username,4127,2,4149,SANSwitch Policy,25,311 1 ::1 09/23/2008 08:31:27 22,8153,0,8111,0,4130,FQDN2,4136,1,4142,0
X.X.X.11,username,09/30/2008,09:05:39,IAS,SERVER,25,311 1 ::1 09/23/2008 08:31:27 22,8153,0,8111,0,4130,FQDN2,4294967209,120,4294967210,50,26,0x000006340102,4108,10.41.11.11,4116,0,4128,SANSWITCH0,4154,Use Windows authentication for all users,4155,1,4129,DOMAIN\username,4127,2,4149,SANSwitch Policy,8136,0,4136,2,4142,0
Which show that the policy "SANSwitch Policy" is being called by the NPS server when the switch attempts to log in.
Do you think that the fact there is nothing being recorded in the Event Viewer is linked to problem?
Phil- Edited by Pifco19 Tuesday, September 30, 2008 10:07 AM
Tuesday, September 30, 2008 9:26 AM -
Hi Phil,
I haven't tested behavior when using the default connection request policy "Use Windows authentication for all users" which is what you appear to be using. Perhaps when this policy is matched there are no access granted or denied events generated - I will need to access my switch to test this but I'm away from it at the moment. Is this the connection request policy that you've been using with IAS? You might be matching this policy if it is first in the processing order and thus preventing a match with other policies you've created. By default, this policy should be assigned an order of 999999, but it's possible to change that either intentionally or by accident.
What are your client authentication requirements?
-GregTuesday, September 30, 2008 5:58 PM -
Hi Greg
I have always used the "Use Windows Authentication for all users" policy on my IAS server, and have never had reason to alter that. Is that incorrect practice?
We are using the same policy on the NPS server, and it is the only one; so it is to be expected that it is being matched.
Our client authentication requirements are that the user logging on should be a member of a particular AD group, and this is configured in the "Use Windows Authentication for all users" policy on the NPS server.
Thanks again for your help.
Cheers
PhilWednesday, October 1, 2008 8:52 AM -
Hi Phil,
I just tested this on my switch and I do see event ID 6272 and 6273 when I use the default connection request policy. You can't use this policy with NAP, but that doesn't affect your situation.
Here is what it looks like in my logs:
10.0.0.3,WOODGROVEBANK\user1,10/01/2008,14:01:59,IAS,NPS1,4,10.0.0.3,5,50001,26,0x0000000902114661737445746865726E6574302F31,61,15,30,00-0D-28-C0-48-41,31,00-11-11-7A-A2-15,6,2,12,1500,4108,10.0.0.3,4116,0,4128,802.1X Switch,4154,Use Windows authentication for all users,4155,1,4129,WOODGROVEBANK\user1,4130,WOODGROVEBANK\user1,4149,Test network policy,25,311 1 fe80::3522:712f:af15:314f 05/12/2008 15:44:39 39285,4132,Microsoft: Secured password (EAP-MSCHAP v2),4127,11,8153,0,8111,0,4136,1,4142,0
10.0.0.3,WOODGROVEBANK\user1,10/01/2008,14:01:59,IAS,NPS1,25,311 1 fe80::3522:712f:af15:314f 05/12/2008 15:44:39 39285,4132,Microsoft: Secured password (EAP-MSCHAP v2),4127,11,8100,0,4120,0x01574F4F4447524F564542414E4B,4108,10.0.0.3,4116,0,4128,802.1X Switch,8153,0,4154,Use Windows authentication for all users,4155,1,4129,WOODGROVEBANK\user1,4130,WOODGROVEBANK\user1,4149,Test network policy,8136,1,7,1,6,2,65,16777222,81,0x0133,64,16777229,8111,0,4136,2,4142,0
Looks like the ::1 you were asking about is the Link-local IPv6 address of the NPS server. I see this whether or not IPv6 is enabled on the network connection. I don't think this is what is causing the problem though. You should be seeing authentication events on NPS.What authentication methods are you using on the client side? Please check the client logs under Applications and Services\Microsoft\Windows\Wired Autoconfig\Operational (if Vista) or the Application log (if XP). You are looking for event ID 15514 which should provide reason why the authentication failed from the client perspective.
-Greg- Proposed as answer by Greg LindsayMicrosoft employee Wednesday, October 8, 2008 7:58 PM
Wednesday, October 1, 2008 9:16 PM -
Just to add, if you look at the NPS server's Security Logs, do you see any events related to the client's authentication? If you are configuring your CRP to reflect the IAS' CRP, you should make sure that you have not checked "override network policy authentication settings" in the Authentication Methods.
You should process authentications at the Network Policy layer.
Clay Seymour - MSFT- Marked as answer by Greg LindsayMicrosoft employee Tuesday, October 14, 2008 9:49 PM
Monday, October 6, 2008 4:36 PM