In this post, I will be talking on how joining domain using smart card works. Long time ago, I started working on smart cards, and I was obsessed with the idea of using smart cards as a replacement to normal passwords. Back then, I usually tend to make all network administrators using smart cards only, and never use their passwords directly. I went to the extreme of randomizing network admin passwords, and only provide them with a smart card and its PIN. This way, network admins will not be able to use their passwords if they are so lazy using smart cards.

To do this, you must work hard to make sure every service in your network can talk using Kerberos, so that smart card authentication works, and single sign on is your hero in such case. You do not want a password prompt appearing on your screen, when all you have is a smart card and a PIN.

Things worked good for me, to the extreme that we enrolled all management and key people with smart cards, and we randomize their passwords to force the use of smart card only. Of course, smart cards come with a management overhead, and I had to work on a Microsoft Smart Card Management solution, to facilitate the enrollment and retirement of smart cards, but that’s a different story.

Joining domain using smart card

One day in the morning, one of the network administrators called me, saying that he wants to Joining domain using smart card using his admin account, but he only had a smart card. His admin password is randomized and he is not able to provide his admin credentials in form of username and password combination. I started to look at the situation from different perspectives.

First challenge is that the machine to be joined to the domain, does not trust our corporate certificate authorities. So, there is a trust issue to start with.

Also, the machine is not joined to the domain yet, so it has no idea what is the domain name and how to treat the certificates in the smart card.

To overcome all those challenges, there are couple of requirements that should be satisfied to facilitate Joining domain using smart card. Those requirements are related to the signing certificate existing inside the smart card:

  • The signing certificate for the network administrator inside the smart card must contain a Subject field that contains the DNS domain name within the distinguished name. If it does not contain this field, resolution to the appropriate domain will fail, causing the domain join with smart card to fail.
  • The smart card certificate must contain a UPN in which the domain part of the UPN must resolve to the actual domain. This is required so that the Kerberos client would not be able to find the appropriate domain.
  • Else, the workaround is to supply a hint (enabled via GPO setting X509HintsNeeded) in the credentials user interface for domain join.

Microsoft TechNet article also specify this:
If the client computer is not joined to a domain, then the client will only be able to resolve the server domain by viewing the distinguished name on the certificate (as opposed to the UPN). For this scenario to work, the Subject field for the certificate must include “DC=” for domain name resolution. To deploy root certificates on smart cards for the currently joined domain, the following command can be used [certutil –scroots]”