none
802.1X EAP\ TLS authentication for non domain devices (printers or zero clients)

    Question

  • 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!


    • Edited by AlLeX_ Friday, March 02, 2012 9:54 PM
    Friday, March 02, 2012 9:47 PM

Answers

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

    Sunday, March 04, 2012 6:09 PM

All replies

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

    Sunday, March 04, 2012 2:41 PM
  • 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.

    Sunday, March 04, 2012 5:46 PM
  • 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.

    Sunday, March 04, 2012 6:09 PM
  • 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.

    Sunday, March 04, 2012 6:42 PM
  • 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.

    Monday, March 05, 2012 3:05 PM
  • 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.

    Monday, March 05, 2012 3:14 PM
  • 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.

    Monday, March 05, 2012 5:31 PM
  • 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.

    Monday, March 05, 2012 6:54 PM