SBS Wireless policy

[Andy]

I'm using the document Owen wrote (Configuring Secure Wireless Network
Access with Microsoft® Windows® Small Business Server 2003) and I'm
having problems.

I have a Linksys router connected to my cable modem. My sbs server
(vortex) is connected to the other wired computers through the linksys.
In addition, I have a DI-634M router, being used as just an access
point.

I've configured everything as per the document, but I'm having
problems. I had tried before using WEP but now I'm using WPA and AES
encryption with the new access point. I had uninstalled Certificate
Authority and IAS and deleted all group policy objects and started over
after getting the new access point up and running and started from
scratch.

Vortex is the SBS server, hellknight is the laptop, di-634m is the
access point.

The message on the server is from IAS:
User host/hellknight.hellmouth.local was denied access.
Fully-Qualified-User-Name =
hellmouth.local/MyBusiness/Computers/SBSComputers/hellknight
NAS-IP-Address = 192.168.0.254
NAS-Identifier = <not present>
Called-Station-Identifier = <not present>
Calling-Station-Identifier = 00-0F-3D-AA-09-5B
Client-Friendly-Name = di-634m
Client-IP-Address = 192.168.0.254
NAS-Port-Type = <not present>
NAS-Port = <not present>
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Connections to other access servers
Authentication-Type = EAP
EAP-Type = <undetermined>
Reason-Code = 65
Reason = The connection attempt failed because remote access
permission for the user account was denied. To allow remote access,
enable remote access permission for the user account, or, if the user
account specifies that access is controlled through the matching remote
access policy, enable remote access permission for that remote access
policy.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Heres logs from the laptop (hellknight):

Userenv:
Windows cannot obtain the domain controller name for your computer
network. (The specified domain either does not exist or could not be
contacted. ). Group Policy processing aborted.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Autoenrollment:
Automatic certificate enrollment for local system failed to contact the
active directory (0x8007054b). The specified domain either does not
exist or could not be contacted.
Enrollment will not be performed.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


Any ideas what might be wrong? Any settings that could be stopping the
server from being found? My SBS server is also my primary DNS and DHCP
server for the clients (and I think SBS uses itself as a DNS server as
well).

Thanks
Andy

[Dave Nickason [SBS MVP]]

I have a few ideas I can run by you that may or may not help. Referring
back to Owen's document:

You need to make changes in the ISA RPC settings to allow certificate
enrollment on the client PC (laptop). Also, auto-enrollment needs to happen
when the client PC is connected to the wired network. The laptop obviously
needs the correct certificate installed before it can connect successfully
over wireless, and your laptop appears not to have the cert. This alone
will prevent a successful connection. Auto-enrollment should log a success
shortly after you connect to the wired network and log in.

Your EAP type should not be "undetermined," it should be "Smart Card or
other certificate." I'm not sure if this is because the connection is
failing, or if it's a configuration thing in your IAS Remote Access Policy.
Again, verify your settings against the document - this setting is in the
entry you created under "Remote Access Policy" in IAS.

I'm not sure why you're getting an error referring to the user account
settings. With Owen's method, it's the client PC that is authenticating to
IAS - it'll actually connect even if you just start the computer without
ever attempting to log into a user account. Still, I'd go into AD Users and
Computers and check the remote (dial-in) settings for the laptop, the user
account, and the SBS. All should be set to "Control access through Remote
Access Policy."

I'm not sure you're going to be able to use WPA and AES. This would be a
question for Owen, but anyway it only works if WPA with AES is supported
throughout all your hardware and software. If all else fails, I would try
WPA and TKIP to see if that changes anything. You'll have to change this in
both the WAP and in the wireless GPO, plus possibly somewhere else I'm
forgetting. I tried to use WPA with AES and ran into failed connection
issues that I believe were caused by my WAP not supporting that exact
configuration (I believe the WPA standard technically calls for TKIP, and
that WPA2 is required for AES, but that some access points support it either
way. Mine apparently does not).

If you get the certificate to enroll properly and still can't connect after
that and verifying the settings in AD, please go through the document
carefully and verify that all your settings match. Post back with anything
you have questions about.



"Andy" <***@alum.rit.edu> wrote in message news:***@l12g2000cwl.googlegroups.com...
I'm using the document Owen wrote (Configuring Secure Wireless Network
Access with Microsoft® Windows® Small Business Server 2003) and I'm
having problems.

I have a Linksys router connected to my cable modem. My sbs server
(vortex) is connected to the other wired computers through the linksys.
In addition, I have a DI-634M router, being used as just an access
point.

I've configured everything as per the document, but I'm having
problems. I had tried before using WEP but now I'm using WPA and AES
encryption with the new access point. I had uninstalled Certificate
Authority and IAS and deleted all group policy objects and started over
after getting the new access point up and running and started from
scratch.

Vortex is the SBS server, hellknight is the laptop, di-634m is the
access point.

The message on the server is from IAS:
User host/hellknight.hellmouth.local was denied access.
Fully-Qualified-User-Name =
hellmouth.local/MyBusiness/Computers/SBSComputers/hellknight
NAS-IP-Address = 192.168.0.254
NAS-Identifier = <not present>
Called-Station-Identifier = <not present>
Calling-Station-Identifier = 00-0F-3D-AA-09-5B
Client-Friendly-Name = di-634m
Client-IP-Address = 192.168.0.254
NAS-Port-Type = <not present>
NAS-Port = <not present>
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Connections to other access servers
Authentication-Type = EAP
EAP-Type = <undetermined>
Reason-Code = 65
Reason = The connection attempt failed because remote access
permission for the user account was denied. To allow remote access,
enable remote access permission for the user account, or, if the user
account specifies that access is controlled through the matching remote
access policy, enable remote access permission for that remote access
policy.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Heres logs from the laptop (hellknight):

Userenv:
Windows cannot obtain the domain controller name for your computer
network. (The specified domain either does not exist or could not be
contacted. ). Group Policy processing aborted.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Autoenrollment:
Automatic certificate enrollment for local system failed to contact the
active directory (0x8007054b). The specified domain either does not
exist or could not be contacted.
Enrollment will not be performed.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


Any ideas what might be wrong? Any settings that could be stopping the
server from being found? My SBS server is also my primary DNS and DHCP
server for the clients (and I think SBS uses itself as a DNS server as
well).

Thanks
Andy

[Andy]

Post by Dave Nickason [SBS MVP]
You need to make changes in the ISA RPC settings to allow certificate
enrollment on the client PC (laptop). Also, auto-enrollment needs to happen
when the client PC is connected to the wired network. The laptop obviously
needs the correct certificate installed before it can connect successfully
over wireless, and your laptop appears not to have the cert. This alone
will prevent a successful connection. Auto-enrollment should log a success
shortly after you connect to the wired network and log in.

I'm not using ISA at all. That's optional, correct? I was getting
different problems, and when I thought to check the certificates on
both the laptop and server, I saw there was no computer certificate for
the laptop. I disabled the wireless, connected the wired and rebooted
again. After waiting a little, I did finally see the laptops
certificate on the servers certificates. I also did check the RPC
settings on the laptop, and those are fine (they must be, since a
certifcate was created, correct?)

Post by Dave Nickason [SBS MVP]
Your EAP type should not be "undetermined," it should be "Smart Card or
other certificate." I'm not sure if this is because the connection is
failing, or if it's a configuration thing in your IAS Remote Access Policy.
Again, verify your settings against the document - this setting is in the
entry you created under "Remote Access Policy" in IAS.

Hmm... I wonder why EAP is undetermined. I'll look into that.

Post by Dave Nickason [SBS MVP]
I'm not sure why you're getting an error referring to the user account
settings. With Owen's method, it's the client PC that is authenticating to
IAS - it'll actually connect even if you just start the computer without
ever attempting to log into a user account. Still, I'd go into AD Users and
Computers and check the remote (dial-in) settings for the laptop, the user
account, and the SBS. All should be set to "Control access through Remote
Access Policy."

Understood. I followed the document like a checklist, and still no joy.
Although I can't find any remote settings for the computer accounts
anywhere in AD Users and computers.. they just appear on Users.

Post by Dave Nickason [SBS MVP]
I'm not sure you're going to be able to use WPA and AES. This would be a
question for Owen, but anyway it only works if WPA with AES is supported
throughout all your hardware and software. If all else fails, I would try
WPA and TKIP to see if that changes anything. You'll have to change this in
both the WAP and in the wireless GPO, plus possibly somewhere else I'm
forgetting. I tried to use WPA with AES and ran into failed connection
issues that I believe were caused by my WAP not supporting that exact
configuration (I believe the WPA standard technically calls for TKIP, and
that WPA2 is required for AES, but that some access points support it either
way. Mine apparently does not).

Well, both my WAP and wireless card support WPA and AES; the WAP is a
Dlink DI-634M, and the wireless card is a DWL-G650. Both have AES
listed as an ecryption option, but I guess I'll give it a shot with
TKIP (or whatever that setting is).

Post by Dave Nickason [SBS MVP]
If you get the certificate to enroll properly and still can't connect after
that and verifying the settings in AD, please go through the document
carefully and verify that all your settings match. Post back with anything
you have questions about.

I have. There only odd thing is that when selecting the server
certificate created in the document, it shows up twice on the server.
I've even compared the thumbprints, and they are identical.

Andy

[Dave Nickason [SBS MVP]]

You don't need ISA, and as far as I know, ISA 2004 settings would be the
only thing that would block certificate enrollment.

That EAP thing could be a problem, although I'm not 100% clear on what's
generating that info. I'd just make sure that the setting is correct in IAS
(Smart card or other certificate). Hopefully if it is, having the cert on
the laptop will make it show correctly.

If just having the cert installed and verifying that setting in IAS don't do
the trick, I'd try changing the encryption to TKIP just to see if it works.
After that comes Plan B, which is to try to scare up Owen, but he has some
other commitments right now and he's not around as far as I know. Oh, and
lastly, you could check for other IAS events in the logs. In the IAS
console, open the properties of the top item (Internet Auth Service) and
make sure the boxes are checked to log successful and failed logon attempts.

Post by Andy

Post by Dave Nickason [SBS MVP]
You need to make changes in the ISA RPC settings to allow certificate
enrollment on the client PC (laptop). Also, auto-enrollment needs to happen
when the client PC is connected to the wired network. The laptop obviously
needs the correct certificate installed before it can connect
successfully
over wireless, and your laptop appears not to have the cert. This alone
will prevent a successful connection. Auto-enrollment should log a success
shortly after you connect to the wired network and log in.

I'm not using ISA at all. That's optional, correct? I was getting
different problems, and when I thought to check the certificates on
both the laptop and server, I saw there was no computer certificate for
the laptop. I disabled the wireless, connected the wired and rebooted
again. After waiting a little, I did finally see the laptops
certificate on the servers certificates. I also did check the RPC
settings on the laptop, and those are fine (they must be, since a
certifcate was created, correct?)

Post by Dave Nickason [SBS MVP]
Your EAP type should not be "undetermined," it should be "Smart Card or
other certificate." I'm not sure if this is because the connection is
failing, or if it's a configuration thing in your IAS Remote Access Policy.
Again, verify your settings against the document - this setting is in the
entry you created under "Remote Access Policy" in IAS.

Hmm... I wonder why EAP is undetermined. I'll look into that.

Post by Dave Nickason [SBS MVP]
I'm not sure why you're getting an error referring to the user account
settings. With Owen's method, it's the client PC that is authenticating to
IAS - it'll actually connect even if you just start the computer without
ever attempting to log into a user account. Still, I'd go into AD Users and
Computers and check the remote (dial-in) settings for the laptop, the user
account, and the SBS. All should be set to "Control access through Remote
Access Policy."

Understood. I followed the document like a checklist, and still no joy.
Although I can't find any remote settings for the computer accounts
anywhere in AD Users and computers.. they just appear on Users.

Post by Dave Nickason [SBS MVP]
I'm not sure you're going to be able to use WPA and AES. This would be a
question for Owen, but anyway it only works if WPA with AES is supported
throughout all your hardware and software. If all else fails, I would try
WPA and TKIP to see if that changes anything. You'll have to change this in
both the WAP and in the wireless GPO, plus possibly somewhere else I'm
forgetting. I tried to use WPA with AES and ran into failed connection
issues that I believe were caused by my WAP not supporting that exact
configuration (I believe the WPA standard technically calls for TKIP, and
that WPA2 is required for AES, but that some access points support it either
way. Mine apparently does not).

Well, both my WAP and wireless card support WPA and AES; the WAP is a
Dlink DI-634M, and the wireless card is a DWL-G650. Both have AES
listed as an ecryption option, but I guess I'll give it a shot with
TKIP (or whatever that setting is).

Post by Dave Nickason [SBS MVP]
If you get the certificate to enroll properly and still can't connect after
that and verifying the settings in AD, please go through the document
carefully and verify that all your settings match. Post back with anything
you have questions about.

I have. There only odd thing is that when selecting the server
certificate created in the document, it shows up twice on the server.
I've even compared the thumbprints, and they are identical.
Andy

[Andy]

Post by Dave Nickason [SBS MVP]
That EAP thing could be a problem, although I'm not 100% clear on what's
generating that info. I'd just make sure that the setting is correct in IAS
(Smart card or other certificate). Hopefully if it is, having the cert on
the laptop will make it show correctly.

The cert does seem to be on the laptop. The question is I guess, which
one is the right cert? The CA cert created in Owen's document, the one
created by CEIWC?

Post by Dave Nickason [SBS MVP]
If just having the cert installed and verifying that setting in IAS don't do
the trick, I'd try changing the encryption to TKIP just to see if it works.
After that comes Plan B, which is to try to scare up Owen, but he has some
other commitments right now and he's not around as far as I know. Oh, and
lastly, you could check for other IAS events in the logs. In the IAS
console, open the properties of the top item (Internet Auth Service) and
make sure the boxes are checked to log successful and failed logon attempts.

I'll try that. I did get it to work, just once. It was so odd
though... I shutdown the laptop, and the next time it didn't work.
Very weird.

Andy

[Owen Williams [SBS MVP]]

In article <***@j72g2000cwa.googlegroups.com>, ajj3085
@alum.rit.edu says...

Hi, Andy. I see you started a new thread about your wireless issues. I'm
sorry I have not been around for a while. As Dave Nickason said, I had some
other commitments (family-related) that have been taking up much of my time.

I really appreciate Dave helping out here. He and I have worked together quite
a bit over the past year or so to refine this methodolgy.

Let's see if we can make some progress ...

Post by Andy
The cert does seem to be on the laptop. The question is I guess, which
one is the right cert? The CA cert created in Owen's document, the one
created by CEIWC?

The cert you want is a Computer (not user) cert generated for hellknight. On
my laptop (PC03-LAP), when I open the "Certificates (Local Computer)" MMC and
look in Personal/Certificates, I see one and only one certificate (split due to
newsgroup posting width limitations):

- - - - -
Issued To Issued By Expiration Date Intended Purposes
PC03-LAP.domain.local ClearViewCA 3/4/2007 Client Authentication,
Server Authentication
- - - - -
Friendly Name Status Certificate Template
<None> Computer
- - - - -

Your MMC display should be VERY similar to this. The only differences should
be "Issued To" (hellknight.domain.local), "Issued By" (your CA name), and
"Expiration Date" (probably late 2007 - default is 1 year from when-issued).

Your initial post in this tread included a detailed "access denied" event.
Thanks for posting that. I see some significant differences between what you
are logging and the "access granted" events I am logging. Here is an example
of a SUCCESSFUL event. I have marked (**) notable differences from your event.

Event Type: Information
Event Source: IAS
Event Category: None
Event ID: 1
Date: 12/12/2006
Time: 6:29:21 PM
User: N/A
Computer: PC02-SVR
Description:
User host/PC03-LAP.domain.local was granted access.
**Fully-Qualified-User-Name = DOMAIN\PC03-LAP$
NAS-IP-Address = 172.24.0.9
**NAS-Identifier = 0011500e2bb7
Client-Friendly-Name = Belkin F5D7230-4
Client-IP-Address = 172.24.0.9
Calling-Station-Identifier = 0011500c48fe
**NAS-Port-Type = Wireless - IEEE 802.11
**NAS-Port = 58
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Wireless LAN Access for Domain Computers
Authentication-Type = EAP
**EAP-Type = Smart Card or other certificate

Fully-Qualified-User-Name: Success includes only domain/computer; failure
includes full Active Directory path to computer account. (Perhaps the full
path is included only in failure messages?)

NAS-Identifier: Normally the MAC address of the WAP. I'm concerned you are not
seeing this. Have you verified the WAP's static IP was properly entered in IAS
RADIUS Client setup and the shared secret is IDENTICAL on both? (I keep the
shared secret at or below 22 characters as some WAPs have a limit smaller than
what IAS supports.)

NAS-Port-Type: As specified in IAS Remote Access Policy. Yours shows "<not
present>"

NAS-Port: I'm not 100% sure what this means, but it's always a number when
everything is working. Yours says "<not present>".

EAP-Type: As Dave noted, yours says "<undetermined>" which is a definite
concern.

Concerning AES v. TKIP ... AES is officially supported only with WPA2 although
some widely-used WAPs (even inexpensive consumer-grade ones like the LinkSys
WRT54g) include WPA-AES. AES requires "hardware assist" circuitry which is not
present on all wireless devices. TKIP is supported with WPA and is software-
only. I agree with Dave that you should try setting EVERYTHING (WAP, GPOs,
etc.) to TKIP to see if that works. Once you get that working, you can always
try moving to AES.

The other thing I see at the D-Link web site is that your DWL-G650 is an older
device. There are several versions which require different drivers. You
should be sure you have the most up-to-date firmware and the correct and most-
current drivers for your particular version.

I also see D-Link has a WPA Supplicant available for the RevB version. WinXP
SP2 includes a built-in WPA supplicant and does not normally require 3rd-party
supplicants. But the DWL-G650_revB supplicant includes this info: "Used with
driver 2.36 - 2.42 for WPA support". Now this software pre-dates WinXP SP2,
but I am wondering whether "Used with driver 2.36 - 2.42 for WPA support" means
"we are providing a supplicant because XP [in 2003] does not have one" -OR-
"you MUST use this supplicant to get WPA support." If it's the latter and you
have a RevB, you may need to install that supplicant.

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]
Hi, Andy. I see you started a new thread about your wireless issues. I'm
sorry I have not been around for a while. As Dave Nickason said, I had some
other commitments (family-related) that have been taking up much of my time.

Owen, no problem, I understand, and haven't had time to dig into this
since my last post.

Post by Owen Williams [SBS MVP]
I really appreciate Dave helping out here. He and I have worked together quite
a bit over the past year or so to refine this methodolgy.

I appreciate the help as well.

Post by Owen Williams [SBS MVP]
The cert you want is a Computer (not user) cert generated for hellknight. On
my laptop (PC03-LAP), when I open the "Certificates (Local Computer)" MMC and
look in Personal/Certificates, I see one and only one certificate (split due to
- - - - -
Issued To Issued By Expiration Date Intended Purposes
PC03-LAP.domain.local ClearViewCA 3/4/2007 Client Authentication,
Server Authentication
- - - - -
Friendly Name Status Certificate Template
<None> Computer
- - - - -
Your MMC display should be VERY similar to this. The only differences should
be "Issued To" (hellknight.domain.local), "Issued By" (your CA name), and
"Expiration Date" (probably late 2007 - default is 1 year from when-issued).

Yes, the cert is on the laptop as well as on the server.

Post by Owen Williams [SBS MVP]
Your initial post in this tread included a detailed "access denied" event.
Thanks for posting that. I see some significant differences between what you
are logging and the "access granted" events I am logging. Here is an example
of a SUCCESSFUL event. I have marked (**) notable differences from your event.
Fully-Qualified-User-Name: Success includes only domain/computer; failure
includes full Active Directory path to computer account. (Perhaps the full
path is included only in failure messages?)

I would seem that way.

Post by Owen Williams [SBS MVP]
NAS-Identifier: Normally the MAC address of the WAP. I'm concerned you are not
seeing this. Have you verified the WAP's static IP was properly entered in IAS
RADIUS Client setup and the shared secret is IDENTICAL on both? (I keep the
shared secret at or below 22 characters as some WAPs have a limit smaller than
what IAS supports.)

I am as well, but haven't been able to fix this. The WAP's IP address
is definitely correct, I checked this. I've retyped the secret several
times, but I'll see if using a shorter one will work better.

Post by Owen Williams [SBS MVP]
NAS-Port-Type: As specified in IAS Remote Access Policy. Yours shows "<not
present>"
NAS-Port: I'm not 100% sure what this means, but it's always a number when
everything is working. Yours says "<not present>".
EAP-Type: As Dave noted, yours says "<undetermined>" which is a definite
concern.

Indeed, but as you can see I haven't figured out how to resolve this;-)

Post by Owen Williams [SBS MVP]
Concerning AES v. TKIP ... AES is officially supported only with WPA2 although
some widely-used WAPs (even inexpensive consumer-grade ones like the LinkSys
WRT54g) include WPA-AES. AES requires "hardware assist" circuitry which is not
present on all wireless devices. TKIP is supported with WPA and is software-
only. I agree with Dave that you should try setting EVERYTHING (WAP, GPOs,
etc.) to TKIP to see if that works. Once you get that working, you can always
try moving to AES.

I'll try that now.

Post by Owen Williams [SBS MVP]
The other thing I see at the D-Link web site is that your DWL-G650 is an older
device. There are several versions which require different drivers. You
should be sure you have the most up-to-date firmware and the correct and most-
current drivers for your particular version.

Yes, its older, but I do have the most recent drivers, which are from
2003. This card DID work correctly once before when I was using the
older WAP which only supported WEP.

Post by Owen Williams [SBS MVP]
I also see D-Link has a WPA Supplicant available for the RevB version. WinXP
SP2 includes a built-in WPA supplicant and does not normally require 3rd-party
supplicants. But the DWL-G650_revB supplicant includes this info: "Used with
driver 2.36 - 2.42 for WPA support". Now this software pre-dates WinXP SP2,
but I am wondering whether "Used with driver 2.36 - 2.42 for WPA support" means
"we are providing a supplicant because XP [in 2003] does not have one" -OR-
"you MUST use this supplicant to get WPA support." If it's the latter and you
have a RevB, you may need to install that supplicant.

The card I have is a RevC card, which doesn't require any additional
software AFAIK tell.

I'll post back with my results of using TKIP. The RevC has options for
AES and so does the WAP, so I would think both support them.

Andy

[Andy]

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

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

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

FWIW, when I try to connect wirelessly, it goes almost instantly to
'Windows is unable to log you on to the <ssid> network.'

Andy

[Andy]

OK,

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?

Andy

Post by Andy
Well, I tried with TKIP, and still no luck there.
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...
Are there other settings that would cause IAS to deny login?
FWIW, when I try to connect wirelessly, it goes almost instantly to
'Windows is unable to log you on to the <ssid> network.'
Andy

[Andy]

Sorry for all my posts today but I wanted to post this message from the
client:

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 12/17/2006
Time: 1:59:06 PM
User: NT AUTHORITY\SYSTEM
Computer: HELLKNIGHT
Description:
Windows cannot obtain the domain controller name for your computer
network. (A socket operation was attempted to an unreachable host. ).
Group Policy processing aborted.


Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 12/17/2006
Time: 1:59:16 PM
User: NT AUTHORITY\SYSTEM
Computer: HELLKNIGHT
Description:
Windows cannot query for the list of Group Policy objects. A message
that describes the reason for this was previously logged by the policy
engine.




So the laptop can't connect to the domain controller, but is that
because IAS has already denied the connection, or is that why the
appropritate rule isn't being hit (Wireless LAN policy..)

Andy

[Owen Williams [SBS MVP]]

Andy:

My working hypothesis is that these errors are occurring because wireless
authentication is not working properly so the laptop cannot contact the DC.

If you connect the laptop WIRED, do the errors NOT occur? I will be concerned
if they do.

Another thing you can try (a little more work): Change the WAP's SSID, make
sure SSID broadcast is enabled, and reconfigure the WAP to WPA-PSK rather than
RADIUS. Select a simple pre-shared key (this is a test only). Then see if the
laptop can connect to the SBS domain using the new SSID. IAS, GPOs, etc. are
now out of the picture; the WAP should act as a simple bridge once the PSK has
been validated. If you still can't connect, you may have a hardware, firmware,
or driver issue.

-- Owen Williams [SBS MVP]

In article <***@n67g2000cwd.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Sorry for all my posts today but I wanted to post this message from the
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 12/17/2006
Time: 1:59:06 PM
User: NT AUTHORITY\SYSTEM
Computer: HELLKNIGHT
Windows cannot obtain the domain controller name for your computer
network. (A socket operation was attempted to an unreachable host. ).
Group Policy processing aborted.
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 12/17/2006
Time: 1:59:16 PM
User: NT AUTHORITY\SYSTEM
Computer: HELLKNIGHT
Windows cannot query for the list of Group Policy objects. A message
that describes the reason for this was previously logged by the policy
engine.
So the laptop can't connect to the domain controller, but is that
because IAS has already denied the connection, or is that why the
appropritate rule isn't being hit (Wireless LAN policy..)
Andy

[Andy]

Owen,

I'm reading your previous post now, but I wanted to reply to this one
because its simpler.

I get no such errors connecting with a WIRED connection. WPA-PSK works
just fine (with AES encryption, no less) and in fact this is the setup
I am using now. I figure its at least better than the WEP I was using
with the old router, right?

Andy

Post by Owen Williams [SBS MVP]
My working hypothesis is that these errors are occurring because wireless
authentication is not working properly so the laptop cannot contact the DC.
If you connect the laptop WIRED, do the errors NOT occur? I will be concerned
if they do.
Another thing you can try (a little more work): Change the WAP's SSID, make
sure SSID broadcast is enabled, and reconfigure the WAP to WPA-PSK rather than
RADIUS. Select a simple pre-shared key (this is a test only). Then see if the
laptop can connect to the SBS domain using the new SSID. IAS, GPOs, etc. are
now out of the picture; the WAP should act as a simple bridge once the PSK has
been validated. If you still can't connect, you may have a hardware, firmware,
or driver issue.

[Owen Williams [SBS MVP]]

In article <***@n67g2000cwd.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
I get no such errors connecting with a WIRED connection. WPA-PSK works
just fine (with AES encryption, no less) and in fact this is the setup
I am using now. I figure its at least better than the WEP I was using
with the old router, right?

This is good - it means the basic wireless hardware is working. The RADIUS
stuff _may_ still be problematic, but at least we know a wireless connection is
physically possible with your hardware combination.

-- Owen Williams [SBS MVP]

[Owen Williams [SBS MVP]]

In article <***@73g2000cwn.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
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.

Post by Andy
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.

Post by Andy
Are there other settings that would cause IAS to deny login?
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]

[Andy]

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

My comments are inline.

Post by Owen Williams [SBS MVP]
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.
Ha... I meant outside of IAS :-)

Post by Owen Williams [SBS MVP]
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

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.

Post by Owen Williams [SBS MVP]
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.

Post by Owen Williams [SBS MVP]
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
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.

Post by Owen Williams [SBS MVP]
- - - - -
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
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.

Post by Owen Williams [SBS MVP]
Dial-in Constraints tab: Nothing checked.

My settings are the same.

Post by Owen Williams [SBS MVP]
IP tab: "Server settings determine IP address assignment" selected

My settings are the same.

Post by Owen Williams [SBS MVP]
Multilink tab: "Server settings determine Multilink usage" selected

My settings are the same.

Post by Owen Williams [SBS MVP]
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.

Post by Owen Williams [SBS MVP]
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.

Post by Owen Williams [SBS MVP]
Authentication tab: Nothing checked. Clicking the [EAP Methods] button should

My settings are the same.

Post by Owen Williams [SBS MVP]
EAP Types: Smart Card or other certificate
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).

Post by Owen Williams [SBS MVP]
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.

Post by Owen Williams [SBS MVP]
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

[Andy]

Ok,

Tried with the new settings in place. Now I get 'Windows was unable to
connect to one or more of your wirelss networks..'

Checking the network properties, everything is set, but there are no
certificates checked to be trusted. ON the DC, the cert is checked, so
I'm thinking that the required cert isn't being copied to the laptop
when I refresh group policies.

I'll try to get more info later.

Andy

[Owen Williams [SBS MVP]]

In article <***@48g2000cwx.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Tried with the new settings in place. Now I get 'Windows was unable to
connect to one or more of your wirelss networks..'

I know it's not what you were hoping for, but it is progress! At least the
laptop now recognizes YOUR wireless network is there.

Post by Andy
Checking the network properties, everything is set, but there are no
certificates checked to be trusted. ON the DC, the cert is checked, so
I'm thinking that the required cert isn't being copied to the laptop
when I refresh group policies.

I agree this sounds like a GPO issue. Most likely the wireless GPO either has
a small configuration error or it is not being properly pushed out to the
laptop during the WIRED connection step.

In "Computer Wireless LAN Policy" -> Computer Configuration -> Windows Settings
-> Security Settings -> Wireless Network (IEE 802.11 Policies), right-click
"802.1x Computer Certificate Wireless LAN Policy" and select Properties.

Preferred Networks tab -> select your secure SSID -> [Edit] button

IEEE 802.1x tab -> [Settings] button (under EAP type)

Verify:
When connecting ... Use a certificate on this computer is selected and
Use simple certificate selection (Recommended) is checked
Validate server certificate is checked
Connect to these server is checked and the box has the INTERNAL name
of your SBS (vortex.hellmouth.local, right?)
Trusted Root Certification Authorities: Scroll down to your CA
(hellmouthCA, right?) and make sure it is checked. It may be listed
twice. If so, it's OK to check both of them. (Checking either one
should also work.) You might want to select the CA and click [View
Certificate] to verify the cert looks like what you are expecting.

When you've verified/fixed all that and have returned to the "Edit <yourSSID>
Properties" page, also verify "Authenticate as guest ..." is NOT checked,
"Authenticate as computer ..." is checked, and "Computer authentication" is set
to "Computer only".

Then OK as necessary and close the GPO editor.

Redo the "Logon to the SBS domain using a _wired_ connection" steps (p. 15 of
the text document). It is VERY important to DISable the wireless NIC while
doing this because Windows XP does not deal well with two active network
connections, especially on the same subnet. Then check the laptop's event logs
to be sure there were no GPO errors. If not, disconnect wired, enable
wireless, and check the laptop's wireless properties to be sure they match the
GPO's - especially the IEEE 802.1x tab -> Settings.

If that looks good, let's see if you can connect via secure wireless. Don't
forget to reconfigure the WAP for RADIUS rather than WPA-PSK!

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]
@alum.rit.edu says...
I know it's not what you were hoping for, but it is progress! At least the
laptop now recognizes YOUR wireless network is there.

Yes, I had no doubt about that, although I wouldn't be surprised
anymore if a Dlink router didn't work right with a Dlink access card...
I had a DI-624 router / AP that after an hour or so of working no
longer routed packets from itself to my Linksys router (which is hooked
to the cable modem). Internal networking worked, but you couldn't get
to the internet anymore over wireless (wired was still fine).. but I
digress..

Post by Owen Williams [SBS MVP]
I agree this sounds like a GPO issue. Most likely the wireless GPO either has
a small configuration error or it is not being properly pushed out to the
laptop during the WIRED connection step.

Are there other settings that could affect GPO, such as Wait for
network on startup?

Post by Owen Williams [SBS MVP]
In "Computer Wireless LAN Policy" -> Computer Configuration -> Windows Settings
-> Security Settings -> Wireless Network (IEE 802.11 Policies), right-click
"802.1x Computer Certificate Wireless LAN Policy" and select Properties.
Preferred Networks tab -> select your secure SSID -> [Edit] button
IEEE 802.1x tab -> [Settings] button (under EAP type)
When connecting ... Use a certificate on this computer is selected and
Use simple certificate selection (Recommended) is checked
Validate server certificate is checked
Connect to these server is checked and the box has the INTERNAL name
of your SBS (vortex.hellmouth.local, right?)
Trusted Root Certification Authorities: Scroll down to your CA
(hellmouthCA, right?) and make sure it is checked. It may be listed
twice. If so, it's OK to check both of them. (Checking either one
should also work.) You might want to select the CA and click [View
Certificate] to verify the cert looks like what you are expecting.

To be clear, I need the CA (hellmouthCA) cert, NOT the one we created
for the DC(vortex.hellmouth.local, friendly vortexDC) correct?

Post by Owen Williams [SBS MVP]
When you've verified/fixed all that and have returned to the "Edit <yourSSID>
Properties" page, also verify "Authenticate as guest ..." is NOT checked,
"Authenticate as computer ..." is checked, and "Computer authentication" is set
to "Computer only".

Those settings are correct; I've checked them several times.

Post by Owen Williams [SBS MVP]
Redo the "Logon to the SBS domain using a _wired_ connection" steps (p. 15 of
the text document). It is VERY important to DISable the wireless NIC while
doing this because Windows XP does not deal well with two active network
connections, especially on the same subnet. Then check the laptop's event logs
to be sure there were no GPO errors. If not, disconnect wired, enable
wireless, and check the laptop's wireless properties to be sure they match the
GPO's - especially the IEEE 802.1x tab -> Settings.

I've been following that procedure to the letter, although your docs
say to check the wireless settings after forcing the gp to update and
logging back on, but before rebooting. I have to note here that I
can't actually do that, because I don't know of any way to see the
wireless network settings until AFTER I enable the wireless card. Once
I do that, the settings appear correct.

Post by Owen Williams [SBS MVP]
If that looks good, let's see if you can connect via secure wireless. Don't
forget to reconfigure the WAP for RADIUS rather than WPA-PSK!

I have done that.

Here's my update: back to Windows cannot logon to the <ssid> network,
and the same messages from IAS. Maybe Dlink didn't implement something
correctly? I did have this working at one point though, but with the
old AP that only supported WEP. I saw on the laptop that the
connection was authenticating and then it connected. Since that
reboot, The auth fails.

It seems to fail rather quickly.. is that to be expected? I do get IAS
messages on vortex (the DC), so it must be contacting it.

Andy

[Owen Williams [SBS MVP]]

In article <***@i12g2000cwa.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Are there other settings that could affect GPO, such as Wait for
network on startup?

Not "Wait for network on startup." I configure that routinely and it has never
caused a problem with secure wireless. On the contrary, it should help since
it makes applying GPOs more reliable. If this is NOT configured, it sometimes
takes 2 reboots to get GPOs to "stick."

Post by Andy
To be clear, I need the CA (hellmouthCA) cert, NOT the one we created
for the DC(vortex.hellmouth.local, friendly vortexDC) correct?

Yes, based on your other posts this is the right cert.

-- Owen Williams [SBS MVP]

[Owen Williams [SBS MVP]]

In article <***@80g2000cwy.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
This is in the IAS policy settings I'm assuming.

Correct: "Wireless LAN Access for Domain Computers" properties ->
[Edit Profile] -> Authentication tab -> [EAP Methods] ->
"Smart Card or other certificate" selected -> [Edit]

Post by Andy
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.

The latter cert sounds like the right one.

When you ran the CEICW, did you enter "vortex.hellmouth.local" as the "Web
server name" on the "Web Server Certificate" page? Normally this should be the
public DNS (or public IP) for your server, to enable remote access, e.g.:

MyServer.PublicDomain.com

(It can be left blank if you don't support remote access.) Sounds like you
provided the private (internal) name instead. That's confusing (as you found)
but I don't think it will affect the wireless configuration as long as you
select the correct cert in IAS.

Post by Andy
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.

Just so you know, my docs assume a "standard" SBS configuration, meaning the
wizards were used for all the basic setup. Most administrators tweak a few
things outside the wizards, but the rule of thumb is: If a wizard can do it,
use the wizard unless you REALLY know what you are doing _in_the_context_of_
_SBS_ (not plain Windows Server 2003).

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

I believe Small Business Remote Access Policy is added by running the Remote
Access Wizard (which configures VPN). I did run that even though I don't use
VPN on my server (except for testing).

Post by Andy

Post by Owen Williams [SBS MVP]
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.

Hmmm ... this could be significant! I'm glad you added the other settings.

Post by Andy

Post by Owen Williams [SBS MVP]
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.

Yeah, I believe "No encryption" is checked by default, and wireless access
should work with it checked. But leaving it checked (in theory) permits an
unencrypted connection which sort of defeats our purpose here! 8-)

Post by Andy

Post by Owen Williams [SBS MVP]
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).

Sounds like the right cert.

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]

Post by Andy
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.

The latter cert sounds like the right one.

OK, that's the one selected in IAS.

Post by Owen Williams [SBS MVP]
When you ran the CEICW, did you enter "vortex.hellmouth.local" as the "Web
server name" on the "Web Server Certificate" page? Normally this should be the
MyServer.PublicDomain.com
(It can be left blank if you don't support remote access.) Sounds like you
provided the private (internal) name instead. That's confusing (as you found)
but I don't think it will affect the wireless configuration as long as you
select the correct cert in IAS.

I actually didn't have a public domain name until recently, which is
why I entered the private one. I'm pretty sure in the CEICW I entered
vortex.hellmouth.local

Post by Owen Williams [SBS MVP]
Just so you know, my docs assume a "standard" SBS configuration, meaning the
wizards were used for all the basic setup. Most administrators tweak a few
things outside the wizards, but the rule of thumb is: If a wizard can do it,
use the wizard unless you REALLY know what you are doing _in_the_context_of_
_SBS_ (not plain Windows Server 2003).

Well, the only thing I had done before I released my mistake was create
computer accounts and users... but after realizing the 'right' way to
do it, I deleted the computer account and used the wizard +
connectComputer site to join the domain (and have company web as my
homepage now). This was all before I attempted this setup though. Are
there wizards for DNS and DHCP, as I have been configuring that
'manually.' My SBS 2003 Unleased book arrived today, I will read
through that cover to cover.

Post by Owen Williams [SBS MVP]
I believe Small Business Remote Access Policy is added by running the Remote
Access Wizard (which configures VPN). I did run that even though I don't use
VPN on my server (except for testing).

I told it not to setup VPN; perhaps I should?

Post by Owen Williams [SBS MVP]

Post by Andy

Post by Owen Williams [SBS MVP]
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.

Hmmm ... this could be significant! I'm glad you added the other settings.

Alas, it seems not to have worked..

Post by Owen Williams [SBS MVP]

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

Yeah, I believe "No encryption" is checked by default, and wireless access
should work with it checked. But leaving it checked (in theory) permits an
unencrypted connection which sort of defeats our purpose here! 8-)

Agreed but I thought I'd leave it at unencptyed until I got the
connection up and running ;-)

Post by Owen Williams [SBS MVP]

Post by Andy

Post by Owen Williams [SBS MVP]
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).

Sounds like the right cert.

Hmm.. I guess I'll have to double check, because I'm back to the same
errors.

I deleted all the certs from the laptop, and am attempting to get them
refreshed from GP or auto-enrollment. It had some of the old certs
from previous attempts, and I thought it might be confusing things..

[Andy]

Owen,

Tried a bit of experimenting. I was able to get IAS to auth my laptop,
but NOT how it should be authed.

Here's what I did. I went to the last policy, 'Connections to other
access servers.' I clicked Edit Profile, went to the authentication
tab and deselected everything. I clicked EAP Methods and added Smart
card or cert, and selected the certificate as I did per your
instructions. I clicked OK until I was back at the Connections to
other access servers Properties window, and selected GRANT remote
access permission.

I then setup the WAP to use WPA-EAP and the raduis server. Finally, I
enabled the wireless connection on the laptop and success! There are
some oddities in the success log though, which I think is the problem
I'm hitting setting things up the 'right' way. Here's the success log
(note the not present values for some key fields):

Event Type: Information
Event Source: IAS
Event Category: None
Event ID: 1
Date: 12/19/2006
Time: 7:14:39 PM
User: N/A
Computer: VORTEX
Description:
User host/hellknight.hellmouth.local was granted access.
Fully-Qualified-User-Name =
hellmouth.local/MyBusiness/Computers/SBSComputers/hellknight
NAS-IP-Address = 192.168.0.254
NAS-Identifier = <not present>
Client-Friendly-Name = di-634m
Client-IP-Address = 192.168.0.254
Calling-Station-Identifier = 00-0F-3D-AA-09-5B
NAS-Port-Type = <not present>
NAS-Port = <not present>
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Connections to other access servers
Authentication-Type = EAP
EAP-Type = Smart Card or other certificate


Can it be that for some reason IAS isn't reconizing the WAP as a
wireless device? Any other ideas?

I think the confirms that something is wacky with the way IAS is
working, and not the certficates. Before I changed the Authentication
tab I just set the policy to Grant access, and access was still denied.
That's when it occured to me to setup the Authentication tab as I
would in the proper policy.. and it worked.

Andy

[Owen Williams [SBS MVP]]

In article <***@i12g2000cwa.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Tried a bit of experimenting. I was able to get IAS to auth my laptop,
but NOT how it should be authed.
Here's what I did. I went to the last policy, 'Connections to other
access servers.' I clicked Edit Profile, went to the authentication
tab and deselected everything. I clicked EAP Methods and added Smart
card or cert, and selected the certificate as I did per your
instructions. I clicked OK until I was back at the Connections to
other access servers Properties window, and selected GRANT remote
access permission.
I then setup the WAP to use WPA-EAP and the raduis server. Finally, I
enabled the wireless connection on the laptop and success! There are
some oddities in the success log though, which I think is the problem
I'm hitting setting things up the 'right' way. Here's the success log
Event Type: Information
Event Source: IAS
Event Category: None
Event ID: 1
Date: 12/19/2006
Time: 7:14:39 PM
User: N/A
Computer: VORTEX
User host/hellknight.hellmouth.local was granted access.
Fully-Qualified-User-Name =
hellmouth.local/MyBusiness/Computers/SBSComputers/hellknight
NAS-IP-Address = 192.168.0.254
NAS-Identifier = <not present>
Client-Friendly-Name = di-634m
Client-IP-Address = 192.168.0.254
Calling-Station-Identifier = 00-0F-3D-AA-09-5B
NAS-Port-Type = <not present>
NAS-Port = <not present>
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Connections to other access servers
Authentication-Type = EAP
EAP-Type = Smart Card or other certificate
Can it be that for some reason IAS isn't reconizing the WAP as a
wireless device? Any other ideas?
I think the confirms that something is wacky with the way IAS is
working, and not the certficates. Before I changed the Authentication
tab I just set the policy to Grant access, and access was still denied.
That's when it occured to me to setup the Authentication tab as I
would in the proper policy.. and it worked.

I agree IAS isn't recognizing the WAP. Or, more correctly, that the WAP is
probably not providing IAS with criteria which will match the Wireless policy.
In other words, I'm more inclined to suspect a problem with the WAP than with
IAS. For example, the WAP's implementation of the RADIUS protocols may not be
100% standard. Too bad there are no "D-Link" entries in that drop-down which
normally specifies "RADIUS Standard" ...

Your modification works because the final policy _always_ matches, so that
policy is applied. Essentially, you found a way to get around the failure to
match the correct policy. At that point, the authentication methods are
applied, and - since you can connect - those appear to be configured correctly,
which confirms what you have been saying about dilligently checking all of
those settings. [FYI, for the authentication stuff the WAP acts only as a
middleman, just passing packets between the wireless client and the SBS.]

So, bottom line, I'm inclined to suspect an issue with the D-Link. Your
fleeting success with the previous WAP may indicate (speculating here) that WAP
was OK (at least in a RADIUS sense) but that another item in the configuration
was off, which you have since corrected.

The down side of what you've done is that authentication is now based only on
the certs and not on the computer account being in Domain Computers. In other
words, you've gone from two-factor to one-factor authentication. Since these
are certs rather than passwords, that's probably not a show stopper, but it is
somewhat less secure and something to think about. For example, if your laptop
was lost or stolen could the certs be moved to a different device (which does
not have an account on your SBS)?

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]
@alum.rit.edu says...
I agree IAS isn't recognizing the WAP. Or, more correctly, that the WAP is
probably not providing IAS with criteria which will match the Wireless policy.
In other words, I'm more inclined to suspect a problem with the WAP than with
IAS. For example, the WAP's implementation of the RADIUS protocols may not be
100% standard. Too bad there are no "D-Link" entries in that drop-down which
normally specifies "RADIUS Standard" ...

Indeed. I guess its time to contact DLink's oh-so-helpful "support."

Post by Owen Williams [SBS MVP]
Your modification works because the final policy _always_ matches, so that
policy is applied. Essentially, you found a way to get around the failure to
match the correct policy. At that point, the authentication methods are
applied, and - since you can connect - those appear to be configured correctly,
which confirms what you have been saying about dilligently checking all of
those settings. [FYI, for the authentication stuff the WAP acts only as a
middleman, just passing packets between the wireless client and the SBS.]

Yes, I was attempting to see what exactly was going wrong; the cert.
auths, the rule's matching, etc. So I'm going to play with the rules a
bit, to see if removing port type and keeping Domain computers or visa
versa will work.

Post by Owen Williams [SBS MVP]
So, bottom line, I'm inclined to suspect an issue with the D-Link. Your
fleeting success with the previous WAP may indicate (speculating here) that WAP
was OK (at least in a RADIUS sense) but that another item in the configuration
was off, which you have since corrected.

Well at least now that I have narrowed the issue down I can focus on
this one item instead of rechecking my settings. I'll post back here
for further results. Its a shame though, this is one of their newest
routers..

Post by Owen Williams [SBS MVP]
The down side of what you've done is that authentication is now based only on
the certs and not on the computer account being in Domain Computers. In other
words, you've gone from two-factor to one-factor authentication. Since these
are certs rather than passwords, that's probably not a show stopper, but it is
somewhat less secure and something to think about. For example, if your laptop
was lost or stolen could the certs be moved to a different device (which does
not have an account on your SBS)?

Well I don't actually intend to run like this, just needed to narrow
the options as to why the auth was failing.

Thanks very much, I wouldn't have gotten this far without your
continued support. I"ll report back.. maybe if I get on them enough
they'll patch it in the next firmware. ;-)

Andy

[Owen Williams [SBS MVP]]

In article <***@48g2000cwx.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Indeed. I guess its time to contact DLink's oh-so-helpful "support."

8-)

Post by Andy
So I'm going to play with the rules a
bit, to see if removing port type and keeping Domain computers or visa
versa will work.

That's a GREAT idea. I had the same thought after I submitted my post, but it
was after midnight here and my brain was fried for that day!

Post by Andy
Well at least now that I have narrowed the issue down I can focus on
this one item instead of rechecking my settings. I'll post back here
for further results. Its a shame though, this is one of their newest
routers..

It's an unfortunate truth that newer is not always better. For my personal at-
home SBS, I use a Belkin F5D7230-4 v1444 wireless router (configured as a WAP).
It works great for secure wireless although it has some other issues (mostly a
somewhat anemic signal strength). But the latest version of this router - same
model, different version - no longer supports RADIUS, only WPA-PSK. <Sigh>

In a similar vein, the popular LinkSys WRT54g versions 2 thru 4 and the WRT54gL
(equivalent to the v4) are all Linux-based (as is the Belkin I use) and work
flawlessly with RADIUS. They can also be upgraded with open source firmware
which adds some nice features such as making the radio transmission power
adjustable. The version now in stores, v5, physically looks the same but uses
a totally different OS and has only 1/2 the flash memory of earlier versions.
I cannot comment about it's RADIUS capabilities since I have not tried this
version. I'm just observing that what you see may NOT be what you get
(depending on what you were expecting)!

Post by Andy
Thanks very much, I wouldn't have gotten this far without your
continued support. I"ll report back.. maybe if I get on them enough
they'll patch it in the next firmware. ;-)

Yes, please do post back. While this has been painful for you, your
experiences will most certainly help others. They helped me, too. I continue
to learn useful things about this methodology, even 18 months after my original
docs were released!

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]

Post by Andy
So I'm going to play with the rules a
bit, to see if removing port type and keeping Domain computers or visa
versa will work.

That's a GREAT idea. I had the same thought after I submitted my post, but it
was after midnight here and my brain was fried for that day!

Owen, here's the update. I removed the Port-Type requirement from the
rule IAS rule, so that only Domain computers remains and just like
that the setup works.

So I think I'll run like this, because I assume that only wireless
clients will trigger the RADUIS authentication anyway, and the wired
computers won't because its actually the WAP forwarding the RADIUS
request, correct?

Are there any security implications by removing the port type rule?
I'm guessing no, because the cert still needs to be authenticated and
you have to be a member of the domain for the rule to apply at all, but
I'd like to confirm this.

Thanks again!
Andy

[Owen Williams [SBS MVP]]

Post by Andy
Owen, here's the update. I removed the Port-Type requirement from the
rule IAS rule, so that only Domain computers remains and just like
that the setup works.

Interesting. That pretty much points to the D-Link, IMO. Perhaps
that's why the other fellow I mentioned in an earlier post had trouble
with one WAP which went away by switching to a different manufacturer
and model. Apparently some WAP firmware is not implementing the RADIUS
protocols 100% correctly.

Post by Andy
So I think I'll run like this, because I assume that only wireless
clients will trigger the RADUIS authentication anyway, and the wired
computers won't because its actually the WAP forwarding the RADIUS
request, correct?

Not entirely correct. The same Remote Access Policies are also present
in Routing & Remote Access. (You can verify this by launching the RRAS
MMC.) Although RRAS can be configured to require RADIUS authentication,
by default on SBS it's configured to use Windows Authentication. This
is true even after running through the secure wireless setup. So, Dial-
in and VPN can bypass RADIUS.

Post by Andy
Are there any security implications by removing the port type rule?
I'm guessing no, because the cert still needs to be authenticated and
you have to be a member of the domain for the rule to apply at all, but
I'd like to confirm this.

In your particular case I don't think the preceding info matters. Dial-
in requires modems connected to the SBS (which I presume you don't have)
and VPN on SBS requires you to run the Remote Access wizard which you
said earlier you have not done. VPN also requires forwarding TCP port
1723 to the SBS.

-- Owen Williams (SBS MVP)

[Andy]

Post by Owen Williams [SBS MVP]
Interesting. That pretty much points to the D-Link, IMO. Perhaps
that's why the other fellow I mentioned in an earlier post had trouble
with one WAP which went away by switching to a different manufacturer
and model. Apparently some WAP firmware is not implementing the RADIUS
protocols 100% correctly.

I'll have to contact DLink to see what their response is.

Post by Owen Williams [SBS MVP]
Not entirely correct. The same Remote Access Policies are also present
in Routing & Remote Access. (You can verify this by launching the RRAS
MMC.) Although RRAS can be configured to require RADIUS authentication,
by default on SBS it's configured to use Windows Authentication. This
is true even after running through the secure wireless setup. So, Dial-
in and VPN can bypass RADIUS.

I think the RWW will be fine for me, although it seems that VPN is
still an option.

Post by Owen Williams [SBS MVP]
In your particular case I don't think the preceding info matters. Dial-
in requires modems connected to the SBS (which I presume you don't have)
and VPN on SBS requires you to run the Remote Access wizard which you
said earlier you have not done. VPN also requires forwarding TCP port
1723 to the SBS.

That's correct, no modems and no VPN. If I do implement VPN, I'll keep
this in mind though.

[Owen Williams [SBS MVP]]

Post by Andy
I'll have to contact DLink to see what their response is.

I think we both know what that will be! ;-)

But it's certainly worth a try. I would also check their web site for
firmware updates every 3 to 6 months. They may slip in a fix without
admitting anything was wrong.

-- Owen Williams (SBS MVP)

[Owen Williams [SBS MVP]]

In article <***@79g2000cws.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
Well, the only thing I had done before I released my mistake was create
computer accounts and users... but after realizing the 'right' way to
do it, I deleted the computer account and used the wizard +
connectComputer site to join the domain (and have company web as my
homepage now). This was all before I attempted this setup though.

Configuring computer accounts outside the wizard would have been an issue
because linking the GPO where my docs say is NOT where the accounts are created
when you DON'T use the wizard. But since you've corrected that, it would seem
to be a moot point.

Post by Andy
Are
there wizards for DNS and DHCP, as I have been configuring that
'manually.' My SBS 2003 Unleased book arrived today, I will read
through that cover to cover.

DHCP and DNS are configured by the SBS integrated setup and the CEICW. There
is no requirement to manually configure these (and I usually don't touch them)
although some SBS consultants do tweak them, primarily:

* DHCP: add excluded address ranges
* DHCP: add reservations (such as for WAPs)
* DNS: add foward lookups for certain names, such as a friendly WAP name

I can tell you that messed up DNS is one of the most common reasons for SBS
networking problems.

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]
Configuring computer accounts outside the wizard would have been an issue
because linking the GPO where my docs say is NOT where the accounts are created
when you DON'T use the wizard. But since you've corrected that, it would seem
to be a moot point.

I would hope so. I guess I'll see as I go through the book.

Post by Owen Williams [SBS MVP]
DHCP and DNS are configured by the SBS integrated setup and the CEICW. There
is no requirement to manually configure these (and I usually don't touch them)

So the wizard can handle the public DNS records as well? Hmm, I'll
have to go through it again and see.

Post by Owen Williams [SBS MVP]
* DHCP: add excluded address ranges
* DHCP: add reservations (such as for WAPs)
* DNS: add foward lookups for certain names, such as a friendly WAP name

That's basically all the tweaking I have done; I've also added DNS
entries for the public domain name I have (I know, I should be using
hosted... but this is just my personal server).

Post by Owen Williams [SBS MVP]
I can tell you that messed up DNS is one of the most common reasons for SBS
networking problems.

I'm fairly sure that's not the problem here, as my DNS seems to be
running fine.

[Owen Williams [SBS MVP]]

In article <***@48g2000cwx.googlegroups.com>, ajj3085
@alum.rit.edu says...

Post by Andy
So the wizard can handle the public DNS records as well? Hmm, I'll
have to go through it again and see.

No, the public DNS is normally handled by your ISP or DNS service provider.
For example, I usually use DynDNS.com. (You do provide the public DNS in the
CEICW to configure the self-signed cert for remote access purposes.) And
notwithstanding the Microsoft "party line", most SBS consultants do not
recommend using SBS to host a web site. The rule of thumb is to minimize how
SBS is exposed to the Internet. In general, this means only allowing access to
e-mail, Remote Web Workplace, VPN, and direct Remote Desktop - and then only if
required by the specific situation.

-- Owen Williams [SBS MVP]

[Andy]

Post by Owen Williams [SBS MVP]
No, the public DNS is normally handled by your ISP or DNS service provider.
For example, I usually use DynDNS.com. (You do provide the public DNS in the
CEICW to configure the self-signed cert for remote access purposes.) And
notwithstanding the Microsoft "party line", most SBS consultants do not
recommend using SBS to host a web site. The rule of thumb is to minimize how
SBS is exposed to the Internet. In general, this means only allowing access to
e-mail, Remote Web Workplace, VPN, and direct Remote Desktop - and then only if
required by the specific situation.

I see. I don't have problems hosting myself, I will use it as a
learning experience (and I will always keep a hardware firewall
between myself and the internet). So far most of the SBS people here
seem to advise against hosting a site for bandwidth and availability
reasons, neither of which I'm concerned about yet. I've been pretty
good running my own web server and other services before I replaced my
Linux server with the SBS server.. I think i'll be ok ;-)

[Owen Williams [SBS MVP]]

Post by Andy
I see. I don't have problems hosting myself, I will use it as a
learning experience (and I will always keep a hardware firewall
between myself and the internet). So far most of the SBS people here
seem to advise against hosting a site for bandwidth and availability
reasons, neither of which I'm concerned about yet. I've been pretty
good running my own web server and other services before I replaced my
Linux server with the SBS server.. I think i'll be ok ;-)

I would disagree that the main reason SBS people advise against hosting
a site is bandwidth and availability, although those are certainly
considerations for anything but test situations.

The main reason is a security issue: exposing TCP port 80 to the
Internet. This is a commonly probed and attacked port. And SBS does
not provide just web services, it is a domain controller and e-mail
server (among other things) as well. If you are allowing someone on the
Internet to connect to you SBS over HTTP, by definition you have either
forwarded port 80 to the SBS or placed the SBS in a DMZ. Either way,
the firewall appliance may not be providing the protection you think it
is.

-- Owen Williams (SBS MVP)

[Andy]

Post by Owen Williams [SBS MVP]
I would disagree that the main reason SBS people advise against hosting
a site is bandwidth and availability, although those are certainly
considerations for anything but test situations.

That was just what I've seen, I've only started reading this newsgroup
regularly a few weeks ago.

Post by Owen Williams [SBS MVP]
The main reason is a security issue: exposing TCP port 80 to the
Internet. This is a commonly probed and attacked port. And SBS does
not provide just web services, it is a domain controller and e-mail
server (among other things) as well. If you are allowing someone on the
Internet to connect to you SBS over HTTP, by definition you have either
forwarded port 80 to the SBS or placed the SBS in a DMZ. Either way,
the firewall appliance may not be providing the protection you think it
is.

Yes, this is true, and I understand. Since this is a home network
though, I'm not too concerned, and at worse its no worse than having my
Linux server which I was using as a domain controller (via SAMBA), web
server, sql server, ssh server, and a host of other things, including
keeper of my data.

Those that say Linux isn't as much of a target don't look at their logs
much; I was constantly getting hit with someone trying to access my ssh
server, which I fortunately setup to only allow public / private
keypair authentication, not user name / password. You'd think the
attacker would check their logs and see that user / pwd wasn't an
allowed authentication method and move on..