Re: SBS Wireless policy

Owen, thanks so much for continueing to help me troubleshoot this
issue.

My comments are inline.

Owen wrote:
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.

This is in the IAS policy settings I'm assuming. I have only two
choices here and both are labeled vortex.hellmouth.local. One has no
friendly name and has an issuer of the same. The other's friendly name
is vortexDC and issued by hellmouthCA (the name of the CA I chose on
the last reinstall. I'm now selecting the latter cert.

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

Ha... I meant outside of IAS :-)

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:

My setup is more or less vanilla, although I made a few minor changes
outside of the wizards before I knew it was a no-no. Nothing to break
any of the wizards and I can run them fine. I believe I corrected
those errors.

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.)

I actually don't have the Small Business Remote Access Policy rule at
all. The others are there.

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.

That's how I thought it was working, but I never found anything to
confirm this until now.

- - - - -
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.)

I have the latter (802.11 and Other) + Domain computers.

Dial-in Constraints tab: Nothing checked.

My settings are the same.

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

My settings are the same.

Multilink tab: "Server settings determine Multilink usage" selected

My settings are the same.

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

Interesting, I had deleted the policy and recreated it per your
docment, but only had the Service-type setting. I have now added the
other settings.

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

I even had the No encryption checked, I have unchecked it.

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

My settings are the same.

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>

Again, this is the cert we created (vortexDC issued by hellmouthCA).

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.

I don't see any DLink settings so I'm guessing standard should be fine.

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!

Indeed. I think it should work fine though. The old access point I
had which only did WEP did support 802.11 RADIUS, and I did have it
working with that access point and the current card. I believe its
possible, because it did work for quite a few hours... its just that
after rebooting it didn't work, although I may not have given it enough
time..

I'll try again with the new settings as I changed above. I assume the
missing policy shouldn't affect anything, because if it was there, it
should not apply anyway and fall through to the Wireless LAN policy.

I'll post back soon.

Andy

.

Loading