Going passwordless

Edited by: David Draper
This is a showcase article for admins, who intend to go passwordless.
I finally got there and it was quite a ride, so to say.
Some time ago, I was asked to work out a strategy for our Windows domain accounts to go passwordless and I finally finished that task. It took a lot of work to get there. Now I would like to showcase this transition, so that others trying to “go passwordless” are able to judge what it takes.

It was a long journey and therefore, in this article, I will not fast-forward through it. Instead I will cover the process thoroughly.

Let me start by defining some  terms I will frequently use:
Passwords: A combination of characters used together with a username in order to prove one’s identity and afterwards get access to some sort of IT system. Not to be confused with: a PIN, an OTP (“one-time-password”) or a password hash.

Being passwordless: Not having a password, or better, not needing to know it, because you will never have to type it, since you use other means of authentication. A password for you may still exist behind the scenes, though, but from an attacker’s perspective, it is impossible to obtain.

SmartCard ("SC" ): A device able to process and store cryptographic secrets like certificates used for authentication. This can be a plastic card, a USB token or even a virtual device. A SmartCard is said to be tamper-proof, you cannot copy the card nor extract its secrets without a PIN, making it suitable for 2-factor-authentication.

SSO: “Single Sign On” | SSO-enabled services: after authenticating once at the windows logon prompt, no further authentication is needed to access these services.

CA: Certification authority. Server-based entity that allows users to (amongst other things) retrieve authentication certificates


I started by determining what type of alternatives to passwords there are and whether our policies/regulations allowed their use. For example, biometric authentication is not an option for us since we work close to the military and use classified documents in our network.

With that in mind, I looked at what Microsoft offers as part of Windows Hello: Configure Windows Hello for Business Policy settings - certificate trust - Microsoft 365 Security | Microsoft Docs. You quickly find that certificate based authentication is at the core of Hello as well, but I found it  unnecessarily complex compared to what I have finally implemented.

Still, I strongly urge you to evaluate “Windows Hello”/”Windows Hello for business” thoroughly. To me it seems Microsoft has done a good job integrating biometric authentication features into Windows 10, which should, if you are allowed and willing to use biometrics, guarantee high user satisfaction (apart from the usual “oops”-moments like Windows Hello bypassed using infrared image - The Record by Recorded Future).

So what was left for me, after ruling out Windows Hello? I went old-school and looked at SmartCards. I am calling this “old-school” because this has been around for years (10-20). I have been using Smartcards for other authentication mechanism before, like disk encryption and VPNs, but never in order to authenticate a domain account.

Could that be hard to setup? I did some research and found out that it is not hard at all. Neither does it cost a lot, nor is it complicated to use… so why wouldn’t everybody be using it already? Let’s see…


1st, you will needea domain CA. Setting up a CA requires some expertise, but at least it’s included in your windows server license.

After you setup your CA, the next steps depend on your choice of SmartCards. I tested with three types: Yubikeys (Model 4 and model 5 NFC), Gemalto ID Prime and virtual smartcards.

These three are fundamentally different. While virtual Smartcards ("VSC") are deviceless, file based SmartCards that are (on purpose) not transferrable to other machines as they are bound to the TPM module of a single machine, Yubikeys and the Gemalto one are transferrable and usable almost anywhere.

The Yubikey 5 NFC is a combo device consisting of SmartCard and Smartcard Reader, the Gemalto card requires a hardware reader (like a suitable slot in your laptop or some device like this one depicted, ID Bridge CT700).

If money plays a role in your deployment (I am tempted to say, “It shouldn’t, as this is a very important key component of your network.”) please note: virtual SmartCards are free. Yubikeys are quite cheap since you don’t have to pay for an extra reading device like you have with the Gemalto card unless you want to use the Yubikey in a contactless manner. Then you will have to buy another reader that features NFC.

Definition: NFC (Near Field Communication)

My own choice would be the Gemalto, but this is mainly because our door system can work with the same card. Users would need only one card for both door- and domain user authentication!

Imagine that, users need the SmartCards to get back from the cigarette break to their desk, which means they'll have to take the card with them,which will guarantee that their screen is being locked (which happens automatically when they remove their card from the reader)!

So when you choose a SmartCard model and you happen to have RFID-secured doors, make sure to ask if that card works with your door system as well (and please make perfectly sure that the guy you talk to knows his stuff).

Ok, after choosing a card type, you enroll a certificate on it. The process is usually well documented by the manufacturer, for example here:
Setting up Smart Card Login for User Self-Enrollment – Yubico and
Microsoft Documentation - Virtual SmartCard Rollout

Before enrolling, you will have set up a PIN for the device, some number usually, maybe 6 digits, maybe 10. This PIN exists together with a PUK which is able to reset a forgotten PIN or even unlock a card that has been locked because of too many wrong PIN authentication attempts.

Now look at this: before, the admin “tortured” you with password policies, possibly requiring you to use a password/passphrase with a length of 12 or more characters, including special characters, and also, this lock screen asking for it again and again, while now, you simply present your SmartCard and type this neat 6 digits and you’re in :-)
But wait…


Ask the man on the street:

Now ask that same man

...which leads us to the question

How does a SmartCard operate?

On a SmartCard, there is an OS, which starts, as soon as the Card is connected. This OS is very simple and all it does at logon is release cryptographic keys when the correct PIN is presented.

The keys it releases, are they like a password?

Well, somehow yes. The entity you present it to (not Windows, but your SmartCard Reader) will use it to authenticate you. But it’s not the PIN that authenticates you to windows. The PIN only authenticates to the SmartCard and the card itself releases a certificate which windows uses to authenticate you to the domain controller who originally created and issued that certificate.
So the answer to the previous question:

'What is more secure, some long password like “JHGU/zguv(/&go87f7” or some random PIN like 638956, the LATTER BEING USED IN CONJUNCTION with a SmartCard?'

...has to be: The SmartCard+PIN is more secure. This, not only because it is 2FA, but because even if that password we compare with looks strong – with a strong adversary that has “unlimited” computing powers, it can be cracked if you only obtain the hash.

Also, think of usability. After people get used to using a SmartCard, for most use cases, they won’t like to return to a password. They will possibly even get rid of these post-its with passwords that you might find from time to time as well, after all.

And even a short, six-digit-PIN is quite secure. Think about it: 6 digits can form 1,000,000 different combinations. An attacker, who somehow gets hold of your SC, will have only a few attempts (let’s say 5) until this card locks for good – how could he possibly guess the correct PIN with only 5 attempts on 1,000,000 combinations?

Now the other way round: if someone sneaked behind your chair and saw you entering your PIN “638956” which he is able to memorize, he still needs to get his hands on your card as well.

Ok – summed up, SCs + PIN are pretty secure compared to passwords. I’ll look at further important details of this question in the final section called “things better NOT left unspoken”.

Let’s see where this leaves us.

We have a SC which we can use to authenticate securely at our windows machine. Next, we will need to look at all the use cases there are which will require testing.



We (me / the company I work for) use, pretty much like most companies:

  • An inhouse mail server (Exchange)
  • A document management system (SharePoint)
  • File Servers (Linux/Windows)
  • RDP connections to other systems (Windows/Linux)
  • And, last but not least, password managers that utilize master passwords
  • Ah, and there is that VPN solution, which in our case, luckily doesn’t require any passwords, but has its own SC based authentication already built-in

All these entities require authentication. With passwords, most of these utilize my domain logon. So in most cases, this was even SSO (with the logical exception of the password manager, of course).

Will SSO continue to work with SmartCards?

Mail: This one is easy. In my org, we use an on-premises exchange server with outlook. All continues to work SSO with SCs just like before with passwords, so no additional authentication after the windows logon is needed.

SharePoint: Easy again. SSO just works. In addition to what was possible before, the SharePoint admin could even define stronger authentication for certain sites by requiring SmartCard authentication (leaving SSO behind voluntarily). Click this link to see how to configure this in IIS: HOW TO: Configure IIS to Leverage Smart Card Authentication (225324)

File Servers:
As our Linux filers use Samba, and Samba, like SMB, allows for SSO even with SCs, the experience remains the same as with passwords.

RDP: Now the harder part starts. When you authenticate to a remote system, windows default settings will require you to enter the SmartCard PIN each time you connect.

What happens in detail: the local SmartCard-Reading device gets forwarded to the remote system. Now the remote system “asks” your system’s SC reader for possible credentials it could use.

The reader enlists all usernames - you click on one and immediately - you are asked for the PIN to be entered either on screen, using the normal keyboard (Yubikey and VSC), or the PIN-Pad integrated into the reader (as with Gemalto’s IDBridge 700CT).

Let’s compare that to the previous standard, using passwords with RDP.

You logged on to windows using your password, you started the remote desktop client, selected which system to connect to and… you were just “in”, SSO-style? No, better not.

If you happen to know a thing or two about windows security, you probably won’t have enabled SSO here. Because if you had, your password could possibly be retrievable by a hacker now, even in plain text.

Microsoft’s way to enable SSO for RDP makes the logon password go into RAM in plain text and it’s retrievable from RAM immediately, if the attacker has only managed to elevate his privileges to local admin and at the same time, succeeded to fool the AntiVirus product you use. And, yes, let’s be fair, this would only be possible if you haven’t used “credential guard”, which is a Windows security feature that is not yet commonly adopted.

So with passwords, you should have to enter the password once for each RDP connection you make as well!

On the Linux side of RDP, we admins do connect to Linux servers using xrdp, and xrdp’s struggle to support SCs has been going on for years, see https://github.com/neutrinolabs/xrdp/pull/1825

I could work around this by using a special version of putty that allows for SC auth. GitHub - ufrisk/puttywincrypt: PuTTY smart card and windows crypto support. and pair it with a locally installed xserver, so I may use graphical applications on Linux from remote, too.

Still, if anyone knows an alternative to xrdp with SC support, let me know, I asked that once.

Technical side notes concerning RDP:
If you try this for yourself and you can’t access the SC at the remote end, or receive an error message saying, “SmartCard requires a driver that seems to be missing.” please be aware that you need to install the driver for the SmartCard at the remote system. Some cards work without, some require it and others work, but don’t show all certificates but only 2!

To install a SmartCard Driver on a remote system without the SC being physically inserted, you’ll need to open device manager and click the action "add legacy hardware” or use an appropriate command for installation that uses the “legacy way” (see Yubico installation documentation for example).

If you happen to work over a WAN connection (over internet as in working from home) and that connection has a latency of maybe 30 ms, you’ll also notice, that it takes the remote system’s logon prompt some seconds to list all users on your SC, if you have several users saved to it, that is. 

This is because for the enumeration of certificates on the card, some data sending back and forth, takes place over this high-latency WAN. 

So imagine an admin like me working from home, having an SC with 5 certificates for various purposes – each time I use RDP over internet, I have to wait up to 10 seconds accompanied by "checking status" (as shown in the next screen shot) until the logon prompt will even offer to choose an account and accept my PIN. That is surely no use case for the standard employee, but for admins, it will teach you to be patient.

Once I contacted Yubico support about this problem. They did anything but resolve this ticket but instead closed it by telling me “The issue is not reproducible as the issue is happening over VPN and for us it is not reproducible without the VPN”. It should be obvious that this is not related to my personal VPN.

On to the next aspect: Password Managers

Imagine you are using KeePass Password Safe and you wanted to unlock your password database with a SmartCard – how do you do it? On the plugin site, you find https://keepass.info/plugins.html#smartcert which supports certain Yubikeys at least.

But keepass does not work with VSCs, nor does it like my Gemalto Card.

Luckily, I found a workaround. You may configure keepass to use a certain user identity to unlock the database automatically (see lowest option in the last screenshot).

So I setup a dedicated keepass user and start keepass as different user using Shift right-click.

This will of course work with any possible SC, so for keepass, we definitely have found a workaround you may call a solution.

Please note that if you hope to use auto-lock-after-time features of keepass, you’ll have to set those to close keepass and not lock it. That keepass user account may unlock keepass automatically without further authentication!

As I will not cover all other popular password managers here, I would love to see some feedback from the readership about how they solve it with their application and SC authentication.

While this aspect should be smooth for most of you, the next aspect should have been smooth for me, but proved to be a challenge as well: home office usage.

While our VPN solutions have always had separate SCs for connecting, they didn’t prove to be fully mature regarding their support for SmartCards “in session”. Let me explain: we run 2 Linux based thin client solutions for VPN access that are able to redirect Smartcards, however each has different problems:

Solution one only supported Yubikeys and had problems reusing the key after you locked the session. Even worse, it didn’t support using SCs for RDP double-hopping. (as in thin client->remote system1->remote system 2).

The manufacturer support however solved that after a few weeks and it’s pretty stable now.

Solution two proved to be good with their SC support, although it didn’t support VSCs due to the lack of TPM support on the thin client. Else, it works with both SCs I tested with, allows double hopping and had no stability problems.
The last problem I’d like to mention is not a use case of its own, but still very important: It’s about the SC readers. Of course, USB based SCs like the Yubikey should pose no problem, but if you look at them closely, you will notice that plugging and unplugging that key each time you leave your desk will not please anyone. If you do it 5 to 10 times a day, that’s 10-20 times sliding it out of or into the port, which means thousands of times per year!

This will definitely wear out any USB port in a few years.
The specification for USB-2.0 type A standard defines rather low durability requirements: Only 1,500 insertions have to be possible, while for USB3, the number is much higher, 5,000 as I heard. Still, for regular heavy usage, unless you use an exchangeable USB extension cord as workaround, you should consider using an NFC reader instead, which works contactless.

Of course, NFC comes with new problems… not only do the costs of the NFC readers exceed the cost of the Yubikey itself, but you need to test out if NFC is supported for all your use cases (should be supported for most of them, if not all).

Having a traditional SC that comes with a reading device which is unlikely to wear out in the next years has advantages in this respect.

Having a deviceless SC like Microsoft’s VSCs is of course not only free but also worry-free when it comes to wearing out. Advantage deviceless, here!

And there’s another issue with some of these readers: if we set up a GPO that locks the session as soon as the SC is removed, any temporary reader malfunction will lead to screen locking. For example, some of the NFC readers I tested would, from time to time every few hours, simply lock the screen since they lost contact to the Yubikey 5 NFC only to re-establish contact a second later!
In the following small section, I will list some practical advice about the PIN/PUK/Masterkey usage and setup

PIN/PUK/Masterkey – my “best practice”

Handing out SmartCards is something the admin will do, as is setting PUKs, or other recovery means like Masterkeys or challenge-response-codes. Please don’t think just because users would potentially be able to administer their card for themselves it’s something they should be doing.

The user should, in my opinion, only be able to change the PIN, nothing else. He should not know the PUK or other recovery means. The user should be required to fulfill a PIN complexity policy (minimum length, possibly even blacklisting certain PINs like 111111), so look closely at what’s possible using your chosen SC solution, and the PIN should be exchanged every year or so.

Things better NOT left unspoken

Ok, if you followed this  far, I guess you’ll agree that going passwordless by implementing SCs is accompanied by some adjustments to your processes. Let’s reiterate why I did what I did and what I really won in the end.

After you setup SmartCard Logon and deploy credentials to your SCs, most users might like this new way, while some others don't since they won't understand the need for change. And it’s very hard to tell a user “you have to use it, because I say” unless you have some new regulations that prove that the company needs to get rid of passwords for good. For so many decades, passwords have been around; surely, they won’t be gone without a fight. So you might see users equipped with a SmartCard but never using it.

That's why I recommend making SmartCards mandatory. This is an option (a simple checkbox) right in the AD user object.

If you check that box, Active Directory will set a new, random password (120 characters!) on its own. It won’t tell the user what it set it to. Any tries to authenticate with the old password will of course fail. Some authentication mechanisms will tell you “this user account requires SC for logon”, while others, like Linux will not hint that and just write “wrong password or username”.
Again: if you set an account to require SCs, that really means, there will be no exceptions.

If you don’t choose that option, how would you be able to tell if your users really use their SCs? Surely there is logging but what good would it do, after it has already happened?

So if you want them secured, DO enforce SC-only logon!

This will of course have to be a decision backed by all non-IT stakeholders as well.

Ok, so we can and should enforce SCs. We can and should enforce complex PINs. We can enforce that the screen is locked automatically if we remove the SCs.

But does this really help to protect the network against attacks?

With passwords around, attackers had the following main attack alleys to impersonate you:

  • install a keylogger (soft- or hardware based) that records your passwords
  • use tools that read out the RAM and retrieve the plain text passwords used for RDP SSO or that are saved to the windows credential manager
  • use tools to retrieve password hashes

Now after having switched to SmartCards, are these 3 main fears really gone now?

Having a keylogger will not suffice anymore. You need PIN and inserted card for an attack, so this one is mitigated. If you use an external PIN pad, even retrieving the PIN alone by means of a software keylogger gets impossible, since that one only attaches itself to the keyboard while the PIN-Pad remains inaccessible. And, attaching a hardware keylogger to the PIN-Pad is not easy, either (please prove me wrong in your comments if you know better).

The RAM tools like Mimikatz will of course remain a big problem. Why? Because even without using a password, there’s still an NTLM password hash in RAM   *surprise, surprise*. It can still be used for pass-the-hash attacks. Can we get rid of those hashes? We could disable NTLM hashes at least and you should look into doing that, but be careful not to try this in your production environment on anything but test accounts, since some applications might work only with NTLM.

What about Kerberos tickets? Those remain attackable, see explanations and mitigations here: Virtual Smart Cards and password hashes in Active Directory 2016 Environments | by Root  | Medium

As you can see in that linked article, even the SmartCard PIN might be retrievable from RAM!

Using an external PIN-Pad-reader should help here (verify that using Mimikatz on your own).

If you choose a SmartCard Reader without external PIN-Pad, please be aware that some drivers allow you to configure PIN caching policies that could govern whether (and how long) to keep the PIN in RAM.

Furthermore, the article hints that you may mitigate the NTLM problem by enforcing daily (or hourly) hash rotation. That's a great advantage over passwords!

And when we look at the danger of credential manager: why use it any longer? After you agreed on requiring SCs by policy for these accounts too, credential manager will no longer be useful and its old passwords are invalid, anyway. Remember: y ou’re able to save several credentials to a SC, not only the one of your main user account.

Finally, what about plain text passwords? As said, behind the scenes, even with mandatory SC logon, there still exists a password. But since you don’t need to enter your password and you don't know it anymore, it can't possibly enter RAM and thus, cannot be intercepted - as simple as that.

What about the probability of losing my SC? What should users do?
Users should immediately inform the admin and have him revoke the certificates. One day later, even if a thief had managed to find a post-it with the PIN, the credentials are no longer valid.

However, within that day, a thief with access to a domain joined machine would be able to do enough mischief, wouldn’t he? So the best would be not only to revoke that certificate but to lock all user accounts saved to that SC for one day. Only that will make abuse impossible.

The difference to passwords is: with passwords, you would simply set a new password if you thought your password is compromised, but with a SC, the old credentials cannot be somehow overwritten immediately but you’ll have to revoke them and that means not before 24 hours will this get effective.



I think you will agree when I conclude that there is a considerable amount of work hidden in "going passwordless". But it’s surely possible with SCs and I think I have shown a lot of caveats and workarounds for most of those, to give you an idea about the effort.

So this leaves you the following possible directions to go from here:

  • deploy SCs for anyone
  • deploy SCs only for some (like for example IT admins or (key) people that have access sensitive data
  • deploy an alternative to passwords that is not SC-based
  • resign and stay with passwords for another year

“That’s all folks”

I hope you will be so kind to leave some feedback after reading and I am looking forward to your related questions or your own SC deployment stories.


Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.