I would go through either of these step sets:
Set 1:
a) export some valid, already working, certificate from another domain member computer and tried it on the problematic workgroup member (import into Local Computer certificate store). This would isolate problems on the workgroup computer.
b) make sure root CAs of the certificates' chains are trusted on the workgroup client
Set 2:
a) in AD, create an empty computer account and ensure it has the dNSHostName attribute. Make sure the object is enabled.
a.2) potentially, the empty password of the newly created computer may pose some problems, so I might go for ADSI Edit and would Reset Password for the computer account
b) add the computer account to the GlobalGroup that is specified in the NPS policy
c) issue a certificate for the computer account with Subject + SAN containing the dNSHostName value preciselly
d) make sure root CA is trusted on the workgroup client
e) try it on the workgroup client, import Local Computer certificate store
Set 3:
a) create a new user account with some UPN, set password, add to the group
b) issue certificate for the user and import on the workgroup client into user's profile
c) make sure RootCA is trusted by the Computer! Note that CRLs are validated by the computer profile, so make sure always that the computer (not just the user) trusts the root CA

ondrej.

There is an amazing pack of free network admin tools. click here to download it

if you are using NPS with network policies based on the membership of domain groups, then the 802.1x certificates must meet the following:
- trusted, valid (date/CRL)
- Enhanced Key Usage (EKU) should be Client Authentication (1.3.6.1.5.5.7.3.2)
- Subject Alternative Name (SAN) should contain an AD identity reference - either UPN (user principal name) or DNS name of an AD computer.
in such case, if you are planning to enroll the non-domain computers for 802.1x access, you can equip the computers with certificates with either DNS name of some AD computer object, or with UPN of some AD user account. This means, either create shadow AD
computer objects for every individual non-domain client and issue the certificate with its DNS name. Or create a single shadow AD computer object for all the non-domain computers and issue some certificates (or copy existing) with the same DNS name. Or do
either of the same with shadow user accounts and issue certificates with UPNs. Your choice depends on what is more convenient for you.
ondrej.

Need to support users over the internet? click here try our remote control online beta

No matther what I try - computer/ user certificate, changing SAN and subject fields, this is the result:


Event Type: Warning
Event Source: IAS
Event Category: None
Event ID: 2
Date: 3/5/2012
Time: 4:55:21 PM
User: N/A
Computer: SERVER-DC
Description:
User host/Test02 was denied access.
Fully-Qualified-User-Name = DOMAIN\host/Test02
NAS-IP-Address = 1.1.1.1
NAS-Identifier = <not present>
Called-Station-Identifier = 00-1E-F7-5A-37-70
Calling-Station-Identifier = 00-07-7D-64-75-76
Client-Friendly-Name = RADIUS_Client_frendly
Client-IP-Address = 10.10.10.1
NAS-Port-Type = Ethernet
NAS-Port = 50733
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = <undetermined>
Authentication-Type = EAP
EAP-Type = <undetermined>
Reason-Code = 8
Reason = The specified user account does not exist.
For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp
.
Data:
0000: 00 00 00 00 ....


I suspect I am missing something related to client EAP/TLS certificate and the object auth in AD.

Need to support users over the internet? click here try our remote control online beta

what exactly do you see in the:
Fully-Qualified-User-Name = DOMAIN\host/Test02
?? This information is actually not obtained directly from the certificate, but rather sent by the client itself. It actually works like the client is extracting some info from the client certificate and sends it to the RADIUS server in the form like:
username:something-extracted-from-the-client-cert
userCertToCertifyIdentity:cert
The client-side-extraction depends on the client side logic actually and can be also modified by the intermediate switch. So it may be, the client device needs some better information in the certificates, or just a different format or something. I would
refer to documentation for the client devices so that they would tell you how should the certificates be formated. We have once got some problems with obsolete HP switche firmware that truncated the client-specified names and the RADIUS received some nonsens.
I would install Network Monitor on the RADIUS server and tried to lookup the info from the EAP traffic itself. You may see some basic info at least.
Also make sure your RADIUS/NPS/IAS server is member of RAS and IAS Servers - or maybe for the purpose of the testing, grant the RADIUS SErver full control over the test computer account directly in AD.
ondrej.

There is an amazing pack of free network admin tools. click here to download it

Fully-Qualified-User-Name = DOMAIN\host/Test02
DOMAIN=Pre-Win2000 name of the domain.
test02 is the user account that I have created but it appears as host/test02 in the log.

There is an amazing pack of free network admin tools. click here to download it

Thanks for yor answer, Ondrej
Here what I am do:
I am trying with both kind of obects - respectively certificates. For user objects - users certificates with SAN - UPN. For computer objects - computer certificates with SAN - FQDN. Also for computer object I set the object attribute "dnsHostname" because
it is not set automatically when created.
The Remote Access Policy consists of two conditions: global group membership and NAS-Port-Type Ethernet.
At the client side I put the client certificate (user or computer) + root and intermediate certificate. I don't put the IAS certificate - may be I must to...will try this.
The error reason is "The specified user account does not exists" - which is part of error msg in the System log of the IAS server.
That's why I am asking whether some atributes are missing because the object is there.

Need to support users over the internet? click here try our remote control online beta

I would go through either of these step sets:
Set 1:
a) export some valid, already working, certificate from another domain member computer and tried it on the problematic workgroup member (import into Local Computer certificate store). This would isolate problems on the workgroup computer.
b) make sure root CAs of the certificates' chains are trusted on the workgroup client
Set 2:
a) in AD, create an empty computer account and ensure it has the dNSHostName attribute. Make sure the object is enabled.
a.2) potentially, the empty password of the newly created computer may pose some problems, so I might go for ADSI Edit and would Reset Password for the computer account
b) add the computer account to the GlobalGroup that is specified in the NPS policy
c) issue a certificate for the computer account with Subject + SAN containing the dNSHostName value preciselly
d) make sure root CA is trusted on the workgroup client
e) try it on the workgroup client, import Local Computer certificate store
Set 3:
a) create a new user account with some UPN, set password, add to the group
b) issue certificate for the user and import on the workgroup client into user's profile
c) make sure RootCA is trusted by the Computer! Note that CRLs are validated by the computer profile, so make sure always that the computer (not just the user) trusts the root CA

ondrej.

Need to support users over the internet? click here try our remote control online beta

The client device is a zero client or printer, so it does not have a user/ computer store.

The certificate chain at the client is ok. This is not the problem. I will check the certificates extensions for syntax errors again.

Need to support users over the internet? click here try our remote control online beta

ok, then the client machines seems to authenticate as computer and not as a user. It takes whatever information is in the ceritificate and tells the RADIUS server to find the Test02 MACHINE account. After that, the client device presents its
certificate (in this case the user's cert) and authenticate as the machine account. So you have a mishmash.
Create a new computer account and issue the certificate for the computer account, not user account. And then verify again what the client sends to the RADIUS.
ondrej.

There is an amazing pack of free network admin tools. click here to download it

Hi all,
Hope this is the right place for my question.
I need some help regarding the following. I am trying to add a zero client to a netwok with 802.1x auth.
There is an AD with Enterpise CA and IAS servers - AD is with Win 2003 SP2 dc's, Ent CA is Win 2008R2, IAS is Win 2003 Sp2. Also there is working 802.1x authentication for normal domain computers which are Windows XP SP2,SP3 and Windows 7.
From zero client interface I can choose the type of authentication for 802.1X - machine or user. Basically, the idea is that device should be able to be authenticated as machine so they can pick up an IP address.

My questions are:
1. For non - domain devices wich type of certificate must be used, user or computer? Because the domain computers use computer certificates with purpose: Client Authentication and Subject Alternate Name: FQDN. I have read in some places in Internet
that for devices that are not domain aware, User certificates must be used with SAN extension: UserPrincipleName filled in.
2. Do I have to create some dummy object in AD that represents the zero client and what type it must be, computer or user. Do I have to set some attributes for that object?

3. Is there anything special about IAS Remote Access Policy that I must create for these devices.
Thank you for you time and help!

There is an amazing pack of free network admin tools. click here to download it