Security

Hello, I'm hoping someone can help me out as I'm fairly new to Aruba, and I'm stuck.

 

I am trying to setup 802.1x on an Aruba 3600.  Because Aruba does not support fail-over for multiple servers with 802.1x, I have to terminate the 802.1x on the controller, and then pass the credentials to my windows servers.  I have a public certification from godaddy that I have installed on the controller, however, users are still getting errors...

 

Radius Server:           *******
Root CA:                    http://www.valicert.com/

The server "*******" presented a valid certificate issued by "http://www.valicert.com/", but "http://www.valicert.com/"....

 

Is there anywhere I can find step by step instructions on setting up an Aruba controller with a public cert for 802.1x termination on the controller, and authentication on a windows server 2008 box? 

 

I hope I am making sense here, my frustration is currently blinding.

 

 

 

 

 

 

#3600

1st problem:

 

When you say fail-over, do both servers have users in the same domain?  If that is the case, you do not need termination.  You only need termination if you want to do fail-through, which is used when you have two servers in different domains, serving up different sets of users.  Fail through is used to detect when there is a negative hit due to bad username/password and then moves on to the next server.  if both servers are in the same domain, disable fail-through, because if a users fails authentication on the first server, he will certainly fail on the second, but there will be a considerable delay.

 

 

2nd problem:

 

The users who want to authenticate via 802.1x need to have valicert root CA and any intermediate certificates installed in their Trusted Root Store.  I'm sure Valicert will give you those certificates. 

 

How to install those certificates into the trusted root store of your clients:  http://technet.microsoft.com/en-us/library/cc754841.aspx

 

 

Hello i got a question for you

What do you mean when you say "Because Aruba does not support fail-over for multiple servers with 802.1x"

 

Do you mean that aruba does not support fail over for example

Let say i got 2 NPS which are my radius and one die  it wont fail over to the secundary

 

Because is that you mean you can put a secondary server and when one fails it will fail over to the other... I have got that scenario working on a client which 2 NPS and if one fail the other will take over the authentications.   Like a redundacy

 

If im confused and you mean something else then correct me please

 

As far i know you terminete the 80.21x on the controller when the radius server is on another remote site to improve performance.

OK, so I was misunderstood.  I was reading "fail-through" to mean the same as radius redundancy. 

 

We've decided to not terminate 802.1x on the controller, but to get certificates on for the NPS server.  I generated a CSR from my NPS server, and I got the certs from Godaddy.  I then installed the certificate to the server, however, users are still reporting that they are getting this:

 

The server "xxx" presented a valid certificate issued by "Go Daddy Class 2 Certification Authority", but "Go Daddy Class 2 Certification Authority" is not configured as a valid trust anchor for this profile. Further, the server "xxx" is not configured as a valid NPS server to connect to for this profile.

 

What am I doing wrong here :(  I'm new to aruba, but not to wireless.

There a manual of it

http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/Step-by-Step-How-to-Configure-Microsoft-NPS-2008-Radius-Server/td-p/14392

 

Check it out... maybe this help you?  its step by step!

thats if you want to configure PEAP EAP

 

And this is how you correctly configure EAP PEAP clients

 

http://community.arubanetworks.com/t5/Authentication-and-Access/Correctly-configure-EAP-PEAP-Windows-client/td-p/43398

 

If you want the highest security you will have to configure EAP TLS but you need certificate on all the clients....

 

I followed that manual pretty closely (except I'm using a public cert from Godaddy).

 

I imported the intermediate cert to the intermediate cert store, and i installed the other cert into IIS.  I select it in NPS, yet i'm still getting....

 

presented a valid certificate issued by "Go Daddy Class 2 Certification Authority", but "Go Daddy Class 2 Certification Authority" is not configured as a valid trust anchor for this profile.

 

To further test the issue, I binded the cert to a https site on the same server, and I'm still getting an untrusted cert warning in my browser.  I guess I need to call Godaddy or something.

Okay

did you buy the certificate of godaddy? you need to buy a certificate for this... there is a special certificate for this... you can ask the sales man of godady i guess so they can sell you the correct one for 802.1x which willl work on a microsoft nps server and well you will use it for peap eap

That certificate you bough did you installed it on the server whichi s the NPS?

you should install that certificate on nps server on personal cert store

 

You need to buy a Cert from godaddy

Now that cert from godaddy goes in the personal cert storage...

 

 

Okay i missed this part

"The server "xxx" presented a valid certificate issued by "Go Daddy Class 2 Certification Authority", but "Go Daddy Class 2 Certification Authority" is not configured as a valid trust anchor for this profile. Further, the server "xxx" is not configured as a valid NPS server to connect to for this profile."

 

Also you said

"imported the intermediate cert to the intermediate cert store, and i installed the other cert into IIS"

 

I apologize i was doing fast reading through my cellphone.

 

Im assuming you were putting Go Daddy Class 2 Certification Authority cert on the intermediate certification authority  storage

That root certificate does not belong to that cert storage...

It belongs to

 

And It belongs to the third party root certification autorites

 

I allready know you know this but you should make sure you see this on the truested root certiication authorites in the client... and also well mark it as the one you are using  to validate that certificate that the server is showing you to prove he is the correct server you are connecting with...

And well to install those certificates you just go to the mmc console add the snap in of the certificates clicks on computer and go to the store and on certificates you right click and click import and well then you browse the certificate.

Here you got the cert if you dont have it

http://www.adelaide.edu.au/its/wireless/support/faq/?template=print

Just scroll down you will see it

 

 

Anyways after that you should see the cert authority on the list...

Guess you already put the certificate you gto from godaddy on your personal storage on your server ( i mean the public key of your server signed by Godaddy private key) and you already configured the connection request policy and also the network policy as well  with the PEAP EAP selecting the certificate you got from godaddy...

 

After that you should be working fine...

 

hope this helps

When you buy an SSL cert from godaddy, you get your cert, as well as an intermediary cert. 

 

I installed the root cert via IIS (complete cert request), but before doing that, I inserted the intermediate sert into my intermediate cert authority, however, the cert is still coming up as untrusted.  I am literally at my wits end :(

---

@versatech wrote:

When you buy an SSL cert from godaddy, you get your cert, as well as an intermediary cert. 

 

I installed the root cert via IIS (complete cert request), but before doing that, I inserted the intermediate sert into my intermediate cert authority, however, the cert is still coming up as untrusted.  I am literally at my wits end :(

---

Versatech,

 

Did you install those certificates on the client?

 

You need to uncheck "validate server certificate" in the wireless profile 802.1x settings.

 

I'm sorry to say but any cert from GoDaddy is going to do this.  We tried everything to resolve it.  What makes the error message go away for us was buying a certificate from Verisign....at 20 times the cost!!!!!

 

So...we just uncheck the "validate server certificate" in the wireless profile setting...

 

 

You also need to install the godaddy Certificates in the trusted certificate store of your clients. This can be done through group policy.

---

@cjoseph wrote:
You also need to install the godaddy Certificates in the trusted certificate store of your clients. This can be done through group policy.

---

cjoseph... Would I have to do that too if I had purchased a verisign cert instead of a godaddy one? 

 

I can't place the cert in the trusted certificate store of all the clients because not all the clients are in our domain.  Looks like I'll have to find another solution then.

It is much less likely with Verisign, but you would have to compare the serialnumber of the CA certificate to see if your clients trust that particular certificate.

 

Not sure if this is still outstanding but with any public certificate issues like this I always run them throug this digicert application which can often fix issues.

 

https://www.digicert.com/util/

 

Just download and run it on the server that the certificate is on and it'll tell you if there's a problem with the certificate and if it can repair it.

 

Cheers
James.

Awesome!

We're actually beating our heads against this as well but I think  I might have some additional info on this. (Apologies if the thread is a little dead but I'm hoping someone else might find this useful.)

 

The problem appears to be with the way the Windows wireless client 802.1x supplicant works. It does not inherently trust the certificates it gets, and this certificate is not the same as a root CA. It would appear that what it's looking for is actually a domain authentication of some sort. Here's the clues we have found:

 

- Manually creating a wifi profile (Windows 7) and then telling it not to verify the certificate allows us to use a self-signed cert from the RADIUS controller. It then allows logins.

 

- When we turn on certificate checking, I no longer even see authorization attempts in the NPS event logs on the RADIUS server. However, what I *do* see are authentication attempts for the MACHINE account in the NPS log files. If I have the cert check turned off, then instead I see my username as the authentication request.

 

So it would appear that the microsoft client, in a domain environment is trying to first do some sort of authentication/authorization for the workstation itself.  On a non-domain computer, or (or a non-windows box) it prompts to accept the cert and just goes with it. 

 

---

@TESC-DanScherck wrote:

We're actually beating our heads against this as well but I think  I might have some additional info on this. (Apologies if the thread is a little dead but I'm hoping someone else might find this useful.)

 

The problem appears to be with the way the Windows wireless client 802.1x supplicant works. It does not inherently trust the certificates it gets, and this certificate is not the same as a root CA. It would appear that what it's looking for is actually a domain authentication of some sort. Here's the clues we have found:

 

- Manually creating a wifi profile (Windows 7) and then telling it not to verify the certificate allows us to use a self-signed cert from the RADIUS controller. It then allows logins.

 

- When we turn on certificate checking, I no longer even see authorization attempts in the NPS event logs on the RADIUS server. However, what I *do* see are authentication attempts for the MACHINE account in the NPS log files. If I have the cert check turned off, then instead I see my username as the authentication request.

 

So it would appear that the microsoft client, in a domain environment is trying to first do some sort of authentication/authorization for the workstation itself.  On a non-domain computer, or (or a non-windows box) it prompts to accept the cert and just goes with it. 

---

We are lacking some detail about your deployment:

 

Are you using a self-signed certificate on your radius server?  Could you distribute that certificate via group policy and sidestep the certificate checking issue?

 

The certificate checking seems to be working out of a different location than the standard certificate stores. For testing purposes, we used a self-signed certificate from the RADIUS server. I then installed the server cert on my test workstation as a root CA.

 

However, in reading up on the subject (http://support.microsoft.com/kb/2518158) it appears that what it's wanting to do is place the certificate into an enterprise store. I tried moving the cert / installing it in various other stores within my certificate management, but it kept coming back to that over and over again. 

 

Current testing setup:

- Aruba 3000 controller, with RADIUS not terminating at controller. (ArubaOS 6.1.3.1)

- RADIUS authentication works when tested with the aaa test within the controller

- Server 2008 R2 with NPS configured (RADIUS Server that is defined in the Aruba)

- Self-signed certificate installed on NPS server.

- Self-signed certificate installed as root CA on the test workstation.

- Certificate is verified as being the one presented by the RADIUS server.

 

Testing options we have tried:

- Non-Windows devices (Apple IOS devices, Apple Macs, Android)

- Non-domain Windows 7

- Non-Domain windows 8

- Domain Windows 7 Pro

 

 

Without seeing the certificate, you have to import the CA that issued the server certificate, not the server certificate itself, per se.  If you got a certificate from a public CA, it would allow you to download the CA  cert and any intermediate certificates so that you would not see that message.

 

I am not sure if that applies in your case.

 

 

Yeah, that's the thing. We don't have a CA configured at this time, and my boss asked me to try a self-signed cert first. In this case, the server's cert IS the CA, because it's the server that issued the certificate, to itself.   In the meantime, we already have a GPO that just tells windows Vista or newer to ignore cert check as a workaround, but I would like it to function as intended if at all possible. A lot to ask of Microsoft, I know.

 

My next step might be to toss up an actual CA, but since we don't have one currently in our domain I'm getting a little pushback from the other domain admins. 

Well, you are in the best position --  by not having an Enterprise CA, because nothing depends on it.  That means, installing one = nothing to break.  Even after you install it, nothing from an AD perspective depends on it.  You just want to install it on a box that will be around so that when you are finished your testing, you can phase in to production.

 

Please show your admins the step-by-step process here:  http://community.arubanetworks.com/aruba/attachments/aruba/115/6113/1/Using+Microsoft+Windows+2008+Server+With+Aruba.pdf