802.1x PEAP/MS-CHAPv2 to IAS - Computer + User Authentication?

[neteng]

Hello all,

Thanks in advance for any advice you may have.

I need to secure wireless access to the company LAN. I've got AD
username/password authenciation via MS-CHAPv2 PEAP working just great.
What I need to do is make sure that users cannot use this login
information on a laptop that is not issued by the company. I figure
the easiest way to do this (since the company does not have a PKI) is
to also configure authentication through the computer accounts. I can
see this option on the Windows Wireless Zero Configurator. What I
would like to do is enforce authentication through both the username
and computer account.

I guess I'm having trouble understanding how exactly to enforce this
on the server side. What type of configuration do I need to create on
the IAS box to enforce this authentication. I'm a little confused as
to the order of operations within the policy configuration....I'm a
route/switch guy, so I'm a little outside of my comfort zone with
this. :)

As a side question, is it possible to set up Intel's PROSet with this
configuration? I did not see an option for computer authentication
there.

Thanks for your time and assistance folks!

neteng

[James McIllece [MS]]

Post by neteng
Hello all,
Thanks in advance for any advice you may have.
I need to secure wireless access to the company LAN. I've got AD
username/password authenciation via MS-CHAPv2 PEAP working just great.
What I need to do is make sure that users cannot use this login
information on a laptop that is not issued by the company. I figure
the easiest way to do this (since the company does not have a PKI) is
to also configure authentication through the computer accounts. I can
see this option on the Windows Wireless Zero Configurator. What I
would like to do is enforce authentication through both the username
and computer account.
I guess I'm having trouble understanding how exactly to enforce this
on the server side. What type of configuration do I need to create on
the IAS box to enforce this authentication. I'm a little confused as
to the order of operations within the policy configuration....I'm a
route/switch guy, so I'm a little outside of my comfort zone with
this. :)
As a side question, is it possible to set up Intel's PROSet with this
configuration? I did not see an option for computer authentication
there.
Thanks for your time and assistance folks!
neteng

Hi there --

What you're discussing is dual authentication, i.e. the authentication of
both the computer and the user before they're granted access. Unfortunately
PEAP and EAP do not support dual authentication.

The only method I'm aware of that allows you to prevent non-domain
computers from connecting to the network is to deploy PEAP or EAP-TLS with
computer certificates that are autoenrolled to domain member computers.

[S. Pidgorny <MVP>]

Using autoenrolled certificates isn't exactly a way of preventing non-domain
or non-SOE computers from connecting to the network: the certificates may be
valid even though the computer is no longer the domain member (because
there's no autorevocation); soft certs may be stolen.

If user authentication is enabled, computer authentication can be skipped
altogether.

Use Network Access Protection (http://www.microsoft.com/nap) for better
admission controls.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

Post by James McIllece [MS]

Post by neteng
Hello all,
Thanks in advance for any advice you may have.
I need to secure wireless access to the company LAN. I've got AD
username/password authenciation via MS-CHAPv2 PEAP working just great.
What I need to do is make sure that users cannot use this login
information on a laptop that is not issued by the company. I figure
the easiest way to do this (since the company does not have a PKI) is
to also configure authentication through the computer accounts. I can
see this option on the Windows Wireless Zero Configurator. What I
would like to do is enforce authentication through both the username
and computer account.
I guess I'm having trouble understanding how exactly to enforce this
on the server side. What type of configuration do I need to create on
the IAS box to enforce this authentication. I'm a little confused as
to the order of operations within the policy configuration....I'm a
route/switch guy, so I'm a little outside of my comfort zone with
this. :)
As a side question, is it possible to set up Intel's PROSet with this
configuration? I did not see an option for computer authentication
there.
Thanks for your time and assistance folks!
neteng

Hi there --
What you're discussing is dual authentication, i.e. the authentication of
both the computer and the user before they're granted access.
Unfortunately
PEAP and EAP do not support dual authentication.
The only method I'm aware of that allows you to prevent non-domain
computers from connecting to the network is to deploy PEAP or EAP-TLS with
computer certificates that are autoenrolled to domain member computers.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.

[James McIllece [MS]]

Post by S. Pidgorny <MVP>
Using autoenrolled certificates isn't exactly a way of preventing
non-domain or non-SOE computers from connecting to the network: the
certificates may be valid even though the computer is no longer the
domain member (because there's no autorevocation); soft certs may be
stolen.
If user authentication is enabled, computer authentication can be
skipped altogether.
Use Network Access Protection (http://www.microsoft.com/nap) for
better admission controls.

Actually that is not correct. If you deploy computer certificates, you
would design network policy/remote access policy to be based on the
computer's group membership; if the client computer were no longer a domain
member, it could not be a member of a group in Active Directory and the
access attempt would be rejected by NPS. In addition, the certificate would
be revoked by an admin if the computer were no longer a domain member, so
the certificate would not be valid.

And NAP is not an authentication solution; with NAP you can verify specific
aspects of the client computer's health state in relation to the health
policy you've defined on the NPS server.

[S. Pidgorny <MVP>]

I stand corrected re. connecting when domain membership is canceled, an
important point.

But a legit certificate doesn't mean that it is presented by a computer that
is a member of the domain and conforms to the SOE (which is usually the
goal, and which is facilitated through NAP).

Case in point: I steal an _image_ of a corporate desktop. The certificate is
there, and it's available to me - unless syskey protection is enabled, or
full disk encryption is used - both are used less widely than corporate
wireless networks. And I can modify the system beyond all recognition - it
will still present a certificate corresponding to a valid domain member.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

Post by James McIllece [MS]

Post by S. Pidgorny <MVP>
Using autoenrolled certificates isn't exactly a way of preventing
non-domain or non-SOE computers from connecting to the network: the
certificates may be valid even though the computer is no longer the
domain member (because there's no autorevocation); soft certs may be
stolen.
If user authentication is enabled, computer authentication can be
skipped altogether.
Use Network Access Protection (http://www.microsoft.com/nap) for
better admission controls.

Actually that is not correct. If you deploy computer certificates, you
would design network policy/remote access policy to be based on the
computer's group membership; if the client computer were no longer a domain
member, it could not be a member of a group in Active Directory and the
access attempt would be rejected by NPS. In addition, the certificate would
be revoked by an admin if the computer were no longer a domain member, so
the certificate would not be valid.
And NAP is not an authentication solution; with NAP you can verify specific
aspects of the client computer's health state in relation to the health
policy you've defined on the NPS server.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.