Wireless Access

im following the guide below:

http://www.fatofthelan.com/technical/using-windows-2008-for-radius-authentication/

but for some reason the machine accounts don't want to pass authentication, is there anything to check what might cause this? the NPS log show the Network Policy doesn't match the Wireless security one, but that computer is certainly in that group.

Could you please provide the Event ID on the NPS Logs or if you could post the entire log from NPS. 

I think you hit the Windows 2008 R2 known issue. First time you installed Certification Authority and Network Policy and Access services, the policy points to CA certificate, not a server certificate which should be used for 802.1x authentication. Please refer to the statement in bold.

Here I am going to explain required steps for Windows 2008 R2 server:

1. On Active directory or any member server (server which joins in the domain) install Active Directory Certificate Services

   On Server Manager click Add Roles

   Click Next to continue

   Choose Active Directory Certificate Services and click Next

   Click Next to continue

   Click Certification Authority and click Next

   Click Enterprise and click Next (Note: You need Windows 2008 R2 Enterprise version to choose Enterprise. If you have Windows 2008 R2 standard, you can only choose standalone)

   Click Root CA and click Next

   Choose Create a new private key and click Next

    Keep dafault values (RSA#Microsoft Software Key Storage Provider 2048 , SHA1) and click Next

   Keep the common name as displayed and click Next

   Set Validity period (5 Years for CA) and click Next

   Keep default values and click Next

   Confirm the setting values and click Install.

2. On Active directory or any member server (server which joins in the domain) install Network Policy and Access Services

    On Server Manager scren click Add Roles

    Click Next to continue

    Click Network Policy and Access Services and click Next

    Click Next to continue

    Select Network Policy Server and click Next

    Click Install to install Network Policy and Access Services

    On Server Manager screen, open the left pane and click on NPS(Local). On Getting started screen, choose RADIUS server for 802.1X Wireless or Wired Connections and click Configure 802.1X

    Choose Secure Wireless Connctions. Leave default name "Secure Wireless Connections" and click Next.

    Click Add to add RADIUS client.

    On New RADIUS client screen, type in Wireless controller's friendly name and IP address. Click on Manual radio button and type in shared secret. Shared secret should match with Wireless controller. [NOTE: If you specify Loopback IP address on Aruba controller, but you should specify Interface IP address. For example, if your VLAN interface IP is 192.168.1.100 and Loopback(Controller IP) is 192.168.1.101, you still need to specify 192.168.1.100 here. You can confirm which IP address tries to speak to Windows 2008 R2 RADIUS by capturing Wireshark trace. Filter TCP 1812 packets to narrow capturing packets.

     Choose Microsoft PEAP. [Note: This article only mentions about PEAP. There is another EAP-TLS. ]

     Choose the certificate "servername.domainname". "domainname-servername-CA" is CA certificate and CA certificate cannot be used for 802.1X. If you only see CA certificate in the window, you need to create server certificate manually. This is Windows 2008 R2 known issue. Please refer to Windows Server Techcenter - Windows server forums - Network Access Protection - Having Issues getting PEAP with EAP-MSCHAP v2 working on Windows 2008 R2. Perform Mr. Greg Lindsay's step (Friday April 22, 2011 5:44pm) Try this:  to re-issue a certificate.

     Specify User Groups such as domainname\Domain Users. [Note: If user cannot be authenticated, you need to Allow each user's dial-in profile]

     Configure Traffic Controls - click Next.

     Click Finish to create NPS Policy.

     Aruba controller setting:

     Confuguration - Security - Authentication - Server Group and add new server group "Win2008"

     Configuration - Security - Authentication - Radius server and add new radius server "Win2008RADIUS"

     On Win2008RADIUS setting, type in Host IP (Windows 2008's IP address). Type key, which should match with Windows 2008's RADIUS client. Click Apply

     Go back to Server Group Win2008 and under Servers click New. Choose Win2008RADIUS and click Add Server. Click Apply.

     Now you can test RADIUS authentication. Diagonostics - Network - AAA Test Server - Choose Win2008RADIUS in the server name. Choose MSCHAPv2. Type in Windows Active Directory's user and password and click Begin Test. If test is successful, your RADIUS configuration is right. If you set Wireshark trace, you can observe Radius requet and Radius accept (TCP 1812) in the trace.

---

@boneyard wrote:

im following the guide below:

http://www.fatofthelan.com/technical/using-windows-2008-for-radius-authentication/

 

but for some reason the machine accounts don't want to pass authentication, is there anything to check what might cause this? the NPS log show the Network Policy doesn't match the Wireless security one, but that computer is certainly in that group.

---

If your computers do not match the policy, please make sure that if you have Windows Groups, it only has the group "Domain Computers'.  The computer will not match if it has "domain computers" and "Domain users".  Create a separate policy, exactly the same with only domain computers and see if it solves the problem.

thanks all, ill come back on the full event log messages

mike: im running win 2008 R2 SP1, so it could be. but wouldn't that already cause an issue with 802.1x user authentication? that certificate isn't only used for machine authentication right?

cjoseph: wouldn't it work if i configure User Groups\Domain Users OR User Groups\Domain Computers? then it can hit on either computer or user.

---

@boneyard wrote:

thanks all, ill come back on the full event log messages

 

mike: im running win 2008 R2 SP1, so it could be. but wouldn't that already cause an issue with 802.1x user authentication? that certificate isn't only used for machine authentication right?

 

cjoseph: wouldn't it work if i configure User Groups\Domain Users OR User Groups\Domain Computers? then it can hit on either computer or user.

 

 

I believe those conditions are AND, not or...

>mike: im running win 2008 R2 SP1, so it could be. but wouldn't that already cause an issue with 802.1x user authentication? that certificate isn't only used for machine authentication right?

I am not sure if you are already using the certificate for "Wired 802.1x authentication". Even the certificate itself is used for another purpose, NPS policy should point the right certificate.

If you look at NPS(Local) - Policies - Network Policy, click on the policy that you have created for 802.1x wireless (Dafault name is Secure Wireless Connection), Choose Properties, Click on Authentication Methods. You will see EAP type in the window. Click on EAP type (for my case EAP type is PEAP. The certificate name should be servername-domainname, such as server.test.local. If the certificate is CA certificate (xxxxx-xxxxx-CA) PEAP does not work.

When I had 802.1x authentication problem, like other authors mentioned, I obtained NPS return code from NPS log.

cjoseph, see the attached file: nps2008-domain-users-computers.png it makes me believe that it is an OR and not an AND, right?

mike, see the attached file: nps2008-certificate.png, i believe im using the correct certificate, not the CA one, right?

below is an example log entry for a machine authentication request that fails (access denied), this happens because the wrong network policy is selected, not the Secure Wireless Connections but the Connections to other access servers. I have double checked and the computer is in the Domain Computers group.

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			BRT\TLT-04$
	Account Name:			host/tlt-04.brt.loc
	Account Domain:			BRT
	Fully Qualified Account Name:	brt.loc/Computers/TLT-04

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	OS-Version:			-
	Called Station Identifier:		D8C7C8C8EF71
	Calling Station Identifier:		0019D2AF162C

NAS:
	NAS IPv4 Address:		192.168.20.128
	NAS IPv6 Address:		-
	NAS Identifier:			192.168.20.128
	NAS Port-Type:			Wireless - IEEE 802.11
	NAS Port:			0

RADIUS Client:
	Client Friendly Name:		IAP-93-IP
	Client IP Address:			192.168.20.128

Authentication Details:
	Connection Request Policy Name:	Secure Wireless Connections
	Network Policy Name:		Connections to other access servers
	Authentication Provider:		Windows
	Authentication Server:		TDC-BRT-01.brt.loc
	Authentication Type:		EAP
	EAP Type:			-
	Account Session Identifier:		-
	Logging Results:			Accounting information was written to the local log file.
	Reason Code:			65
	Reason:				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.

 user authentication goes fine, there is no issue there, the correct network policy is matched and access is allowed.

what could cause this wrong group match? anything else to check or do?

perhaps insert image works beter then using attachments, it seems to do so.

mike, i can try Test AAA server, but that will work fine, as stated before user authentication works, it is the machine authentication that fails because of the wrong match.

if i remove the Network Policy condition User Groups : BRT\Domain Users OR BRT\Domain Computers then the machine authentication is succesful. so somehow that match fails for a reason i don't understand.

i checked the dail-in properties of the computer in AD (i also read the same in the error), but there it is set correctly in my opinion:

Boneyard,

The "Dialin" error is because the account does not have "Allow Dialin" enabled.  The only thing that works to deal with that reliably is to use the "Ignore" option on the remote access policy.  Fix that first and see if it is still hitting that last Remote Access Policy.

Hi Boneyard,

At the Windows Domain management point of view, Group setting such as domain users should work.

Recently I experienced the same situation. Even though I specified domain users in the Network Policy, the user could not connect. I think your choise - Control through NPS policy is absolutely right. In that case, by choosing Dial-in Allow access option resolved the issue.

I think this is a Windows implementation issue. I have my lab in my hand (Windows 2008 non-R2, Aruba 3400 5.0.4.6) so I will try to resolve the right setting. I guess I should have to look into Global Policy.

cjoseph that option (ignore dail-in properties) is turned on, it is by default i believe.

i tried an earlier suggestion of you and created and other profile (Secure Wireless Connections - machine auth) which only includes the windows group \ domain computers and a seperatie profile with only user group \ domain users (i have to look into these different group types sooner then later). and now get a different error, any clue how to solve this?

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			BRT\TLT-04$
	Account Name:			host/tlt-04.brt.loc
	Account Domain:			BRT
	Fully Qualified Account Name:	BRT\TLT-04$

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	OS-Version:			-
	Called Station Identifier:		D8C7C8C8EF71
	Calling Station Identifier:		0019D2AF162C

NAS:
	NAS IPv4 Address:		192.168.20.128
	NAS IPv6 Address:		-
	NAS Identifier:			192.168.20.128
	NAS Port-Type:			Wireless - IEEE 802.11
	NAS Port:			0

RADIUS Client:
	Client Friendly Name:		IAP-93-IP
	Client IP Address:			192.168.20.128

Authentication Details:
	Connection Request Policy Name:	Secure Wireless Connections - machine auth
	Network Policy Name:		Secure Wireless Connections - machine auth
	Authentication Provider:		Windows
	Authentication Server:		TDC-BRT-01.brt.loc
	Authentication Type:		EAP
	EAP Type:			-
	Account Session Identifier:		-
	Logging Results:			Accounting information was written to the local log file.
	Reason Code:			22
	Reason:				The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

 seems machine authentication doesn't do PEAP?

Hi Boneyard,

Yes, it says EAP .. not PEAP

What you want to implement is PEAP, or EAP-TLS?

im just trying to implement machine authentication, is that EAP-TLS instead of PEAP? I could imagine that as the machine probably doesn't enter a username / password right?

so i should configure NPS 2008 for EAP-TLS (certiticate or smartcart for the computer group)?

Hi Boneyard,

I looked at your past update again and found error messages:

Authentication Type:  EAP
 EAP Type:   -

I should correct my past update. Authentication Type is always EAP, and EAP Type shows PEAP or Smart card.. etc.

In your case, because of Reason Code 22, EAP type shows - (Unknown).

Reason Code 22  = The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

This reason code 22 most likely happen if your pc client does not have CA certificate of your domain.

When domain administrator puts pc client into domain, the pc client downloads CA certificate.

To check if your pc client has CA certificate, from Internet Explorer, Tools - Internet Options - Content Tab - Click on Certificates.

Click on Trusted Root Certification Authorities.

Scroll down certificates and find CA certificate. If the servername of CA server is 2008CA, and if domain name is test.local, the CA certificate name is   test-2008CA-CA

Im no NPS expert, but I think the error message means that you don't have EAP-TLS configured under the NPS rule.  I could tell you how to set this up using ClearPass Policy Manager, but NPS is a little less familiar to me.

The link here seems to have some decent info:

http://technet.microsoft.com/en-us/library/cc770622%28v=ws.10%29.aspx

BTW - Machine authentication can use EAP-TLS (machines have to have a "machine" certificate that is signed by the same CA that signed the certificate on the RADIUS server or controller (depending on where you terminate the EAP session)) or EAP-PEAP (the machine will use it's machine name (host/<machine name>) and security ID (SID - basically a domain computer password).

thanks for the replies, got some things to check in the coming time.

how is determined which method EAP-TLS or EAP-PEAP is used by the client for machine authentication?

The machine will use what ever method is setup in the Windows Zero Config utility.  Here is a link:

http://technet.microsoft.com/en-us/library/dd759246.aspx

Basically, if you choose "Smart Card or other certificate", you are using EAP-TLS for all you authentications.  I dont believe you can use TLS for machine and PEAP for user auth (or vice-versa).

ah ok, that makes sense.

so when i use EAP-PEAP for normal user authentication, then EAP-PEAP is also used for machine authentication. is the missing CA certificate as suggested then a logical reason for the machine authentication to fail?

the normal user authentication works fine, it is the machine authentication that fails.

I was having the same issue as the OP... user accounts could authenticate just fine, but the computers wouldn't authenticate. This was making it so our login script wouldn't run unless the person plugged a cable in for the initial login. After that, they could unplug and roam around to their hearts content.

Anyway, the way I finally got it fixed was by changing a few settings so that the computers authenticated using a certificate rather than the computer password.

1. This requires a way to issue certificates to each laptop. I already had a server running MS Certificate Services integrated with Active Directory.
2. I modified my group policy under Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Polocies > Automatic Certificate Request Settings to automatically request a "Computer" certificate.
3. I then let it set for a while to allow my laptops to request these certs.
4. On the NPS server, I created a policy for the computers that has the "Domain Computers" group under Conditions and under Constraints > Authentication Methods has "Microsoft: Smart Card or other certificate". Also, under "Edit..." for that method I have the certificate assigned to my RAIDIUS server by my internal CA.
5. In the Aruba config, under Authentication > L2 Authentication > 802.1x Authenticate Profile > (My Profile Name), I turned off "Termination" ... I think this makes it so my RADIUS server provides the encryption certificate instead of the Aruba controller which allows the computer to select the right certificate.
6. My final step was to modify the group policy for my Wifi networks. Under Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Networks > (My Policy Name) I went to the "Preferred Networks" tab. I selected my SSID and hit "Edit...". Then on the IEEE 802.1x tab I made my "EAP Type" be "Microsoft: Smart Card or other certificate" and the "Authentication Mode" be "Computer only". Under "Settings..." for the EAP type I selected "Use a certificate on this computer" (with the simple selection checkbox checked). I also left the "Validate server certificate" checkbox checked and selected my internal CA from the list of Trusted Root Certification Authorities.

I think that's all I did, though I can't be 100% sure. I do know that watching my IAS logs I can see the machines being sucessfully authenticated now... and, most importantly, the login script runs :).

thanks for the reply and clear explanation. it sounds like a solution, i would rather just use the other option, so no certificates.

do you users still get authentication on username / password also?

The computers no longer authenticate using a username/password, but other devices (like my phone) do. I'm sure if I could change the settings for my SSID to use PEAP and authenticate as a user it would still work as I didn't change those settings on my Network Policy Server (I can't change them, however, because they are pushed by group policy).

I certainly understand wanting to avoid the certificates... that was my original plan, too. I just got to a point where I really wanted to get this working. I found that our German division was already using certificates and started poking around for what was different between our two configs and found the previous post.

The one caveot that I've found is now it looks like I'm getting a certificate warning when I connect my phone (presumably because our internal CA is obvioulsy not trusted by default).

---

@boneyard wrote:

cjoseph, see the attached file: nps2008-domain-users-computers.png it makes me believe that it is an OR and not an AND, right?

 

mike, see the attached file: nps2008-certificate.png, i believe im using the correct certificate, not the CA one, right?

 

below is an example log entry for a machine authentication request that fails (access denied), this happens because the wrong network policy is selected, not the Secure Wireless Connections but the Connections to other access servers. I have double checked and the computer is in the Domain Computers group.

 

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			BRT\TLT-04$
	Account Name:			host/tlt-04.brt.loc
	Account Domain:			BRT
	Fully Qualified Account Name:	brt.loc/Computers/TLT-04

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	OS-Version:			-
	Called Station Identifier:		D8C7C8C8EF71
	Calling Station Identifier:		0019D2AF162C

NAS:
	NAS IPv4 Address:		192.168.20.128
	NAS IPv6 Address:		-
	NAS Identifier:			192.168.20.128
	NAS Port-Type:			Wireless - IEEE 802.11
	NAS Port:			0

RADIUS Client:
	Client Friendly Name:		IAP-93-IP
	Client IP Address:			192.168.20.128

Authentication Details:
	Connection Request Policy Name:	Secure Wireless Connections
	Network Policy Name:		Connections to other access servers
	Authentication Provider:		Windows
	Authentication Server:		TDC-BRT-01.brt.loc
	Authentication Type:		EAP
	EAP Type:			-
	Account Session Identifier:		-
	Logging Results:			Accounting information was written to the local log file.
	Reason Code:			65
	Reason:				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.

 user authentication goes fine, there is no issue there, the correct network policy is matched and access is allowed.

 

what could cause this wrong group match? anything else to check or do?

---

Boneyard,

The reason is because the dialin property on the computer's user account is not enabled.  The "Connections to other access servers" is the last built in rule on the radius server and is normally triggered when nothing else matches.