Re: SBS Wireless policy

In article <1166382641.676490.18700@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, ajj3085
@alum.rit.edu says...

Well, I tried with TKIP, and still no luck there.

OK, at least we know that's not the immediate cause. I would leave the
settings at TKIP for the time being until the other issues get resolved. This
is only because, when there is a problem using WPA, I have higher confidence
TKIP will work than AES.

I think the problem is that IAS for whatever reason is denying the
connection, though I can't figure out why. The cert I select in IAS
and Group policy seem to match...

Just to be sure ... the cert you are selecting MUST be the Domain Controller
cert you create after installing Certificate Services. For my server (PC02-
SVR), the cert is called: pc02-svr.domain.local. You must NOT select the self-
signed cert created by the CEICW, although (at least on my server) it is
physically possible to select that in the "Certificate issued to" drop-down.
The self-signed cert is normally named the same as your public DNS.

Are there other settings that would cause IAS to deny login?

Sure - lots of them! In a later post you say:

Downloaded something called IAS Log Viewer, and it seems the reason the
connection is rejected is because DIALIN_DISABLED. Its applying the
last rule in the policy.

I never see anything about the rule I created and the certificate in
the log, its as if it just jumps to the last rule. Is that expected if
the certificate exchange is failing, or is it not reconizing the
connection as a Wireless -802.11 or Wireless-Other?

If you started with a "vanilla" SBS configuration and just added secure
wireless per my docs, IAS should have four Remote Access Policies in this
order:

Name Order
Small Business Remote Access Policy 1
Wireless LAN Access for Domain Computers 2
Connections to Microsoft Routing and Remote Access server 3
Connections to other access servers 4

(The order of the first two may be reversed and it's OK if they are.)

The first two policies should be set to "Grant remote access permission" while
the last two should be set to "Deny remote access permission".

When a remote access attempt is made, the policies are applied one at a time in
the order listed. The FIRST policy where a match to the "Policy conditions" is
found becomes the controlling policy. If there is no match, the next policy is
tested. This continues until a match is found. The "Policy conditions" on the
last policy ("Connections to other access servers") are:

Day-And-Time-Restrictions matches <any date and time>

This will ALWAYS match and the connection will be denied because the policy is
set to "Deny remote access permissions". So, if you are getting to this policy
it means the connection attempt is NOT matching one of first two policies, more
specifically the "Wireless LAN Access for Domain Computers" policy. You should
take a CLOSE look at that policy.

- - - - -
On my server, the "Policy conditions" are set to:

NAS-Port-Type matches "Wireless - IEEE 802.11" AND
Windows-Groups matches "DOMAIN\Domain Computers"

I believe, though, that I tightened up that policy a while ago (for my specific
wireless hardware) and that it originally was:

NAS-Port-Type matches "Wireless - IEEE 802.11 OR Wireless - Other" AND
Windows-Groups matches "DOMAIN\Domain Computers"

(Your hardware may require the "Wireless - Other" setting.)

Clicking the [Edit Profile] button, you should see:

Dial-in Constraints tab: Nothing checked.

IP tab: "Server settings determine IP address assignment" selected

Multilink tab: "Server settings determine Multilink usage" selected

Advanced tab:
Name Vendor Value
Ignore-User-Dialin-Properties Microsoft True
Service-type RADIUS Standard Framed
Termination-Action RADIUS Standard RADIUS-Request

Encryption tab: Everything EXCEPT "No encryption" should be selected. (The
last step of the procedure I document "hardens" these settings once everything
is working.)

Authentication tab: Nothing checked. Clicking the [EAP Methods] button should
show:

EAP Types: Smart Card or other certificate

and clicking [Edit] should show:

Certificate issued to: <yourSBS>.<yourdomain>.<yourTLD>
Friendly name: <may be blank>
Issuer: <your certificate authority>
Expiration date: <some time in the future>
- - - - -

While you are in IAS, check the RADIUS Client setup for your WAP. Make sure
"Request must contain the Message Authenticator attribute" is checked. As
noted in my docs, "Client-Vendor" should almost always be set to "RADIUS
Standard". I don't think you will need a vendor-specific setting, but you can
check the drop-down to see if one might apply to your WAP.

Having said all this ... I worked with one person who found their WAP (a 3Com
OfficeConnect 11 a/b/g 3CRWE454A72) simply would not work with a RADIUS
configuration. He replaced it with a different unit (ASUS WL-550gE) and the
configuration immediately worked. Now Dave Nickason uses 3Com WAPs so I am not
in any way saying there is a problem with them. It's possible the person
having the trouble misconfigured the 3Com WAP but properly configured the ASUS
WAP. There's no way for me to tell. I mention this because there are such
things a firmware bugs and WAPs that don't work the way their documentation
says!

-- Owen Williams [SBS MVP]
.

Loading