0

I have a Win2K8 server with NPS. I am trying to set my VPN authentication on a FortiGate firewall to authorize users via Radius from my Windows server.

I have two policies configured

  • a Connection Policy defining the client and the Radius secret
  • a Network Policy defining the required AD group membership and the required requesting access server (ie the Firewall)

The Network Policy has the checkbox "Ignore user account dial-in properties" selected.

If the user account has "Control access through NPS Policy" selected on their dial-in properties page, access is denied. If I change it to "Allow access", access is permitted.

If I leave it at "Allow access" and remove the user from the AD group required, then access is granted, which confuses me.

So what is required to get the NPS policy to determine if access is granted regardless of the Dial-In properties selected?

I found the other question on Server Fault which describes this problem, but the suggested solution of reordering the policies does not help.

David Mackintosh
  • 14,293
  • 7
  • 49
  • 78
  • 1
    Have you looked at the event log yet? The NPS Policy Server is going to throw event id 6273 source "Microsoft-Windows-Security-Auditing" events when it denies access to a user, along with some verbose information about the failure. My suspicion is that your policy isn't set-up in the way you think it is and that the you'll find the reason for the authentication failure in the log. – Evan Anderson Jul 12 '13 at 20:26
  • You are correct, there is a difference between "Access CLient IPv4 Address" and "Client IPv4 Address". – David Mackintosh Jul 12 '13 at 20:34
  • I suppose I can live w/o an "Accept" on this one... >smile – Evan Anderson Jul 12 '13 at 20:39

3 Answers3

0

I ran into this issue today... Make sure you are using AD CA and take the computer off the domain and re-join.

Mark_Albin
  • 1
  • 1
0

The solution is: check your policies carefully.

In my case, I didn't read the critieria carefully enough, and both the Connection and Network policies defined referred to "Client IPv4 Address" instead of "Access Client IPv4 Address".

David Mackintosh
  • 14,293
  • 7
  • 49
  • 78
0

I know this is old, but I was having the same exact problem on one computer when trying to connect to our wireless network. I went into my NPS network policy and selected to ignore dial-in properties, and I still could not connect to the network on this computer. I kept on getting an error 65 "The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission." in the event log on the NPS server security log. Eventually, the solution was to remove my computer from AD, delete the AD account, uninstall my network adapters and restart the computer to allow them to re-install automatically. After this I was able to connect to the network and authenticate successfully through the NPS.

Jake
  • 1