OK, so i’m getting in on the Yubikey bandwagon, have read some of the material and watched some content but i’m time poor and looking for answers to some questions I have and haven’t found in the documentation yet.
Does anyone know the answers to the following?
can you use the same yubikey to log into multiple AD domains if you configure AD domain auth with them? i.e., can it hold multiple domain setups on a single key?
will the software generally warn the user before doing something destructive that may wipe their keys? e.g., lets assume the answer to the above is no, will it make it diffiicult to say, wipe your credentials for domain A when plugging in to set up for domain B?
generally speaking, would it be advisable to split business and personal keys due to above concerns (assuming we issue keys as something we do not retrieve, they’re “gifted” to the user forever), or can you reasonably safely store all credentials on the same key(s)?
I’m trying to find the time to read through most of the docs today, but its very jargon filled and locating answers to above is proving difficult. there’s plenty of guides to set up auth types XYZ, but i’m more looking for a “how to not shoot my foot off” danger points before experimenting with them too much and causing problems for my personal accounts
I’m looking to make use of them for MFA for on prem AD domain admins (and later all AD user accounts), MFA for o365/azure sign in, and as a replacement for google authenticator (we recently started doing MFA using the authenticators from MS/google, and have run into issues with people replacing their phones and not backing up/transferring their MFA details - a key they can just plug in will help that for example).
So far the 5 NFC looks like the go for most people, as it works with Phones that have NFC, and the 5Ci doesn’t have NFC, which is a bummer. Damn shame we’re in this transitional period where PCs have limited USB type C, iDevices are still mostly lightning and my Mac and other phones/newer ipads are all going type C (and i don’t think ipads of any form have NFC).
The Windows/Mac/Linux authenticator is pretty neat. Rather than relying on an MFA code on your phone, you can copy/paste direct from the app assuming your key is plugged in. Also it can set up via scanning a QR code displayed on screen, no need to whip out your phone camera.
Idk about AD specifically, but you can definitely authorize/de-authorize the yubi for MFA independently across different services. Where it becomes inflexible is if you want to authorize multiple keys (a backup key) to a single service, I don’t think all services support that (many do though).
For me, I put my gpg keys on it and use those when possible instead of the key directly. This allows me to have a clone as a backup. Works great for ssh keys, encrypting, signing, etc and supports stronger crypto (RSA4096) than PIV. For most MFA implementations though, it will need to be used directly.
IIRC the static password and HMAC token features can be cloned across keys at setup but the other MFA protocols are inherently unique to each key. However, macOS (and possibly other things) will check the serial of the key, so despite using HMAC, a “cloned” backup key won’t work.
not entirely sure yet, still playing/learning. i just know AD supports smart card and yubikey supports it. i’m in the process of standing up a toy AD environment and running through the yubico setup for this, but while they tell you how to configure the different methods they don’t appear to list whether or not any method will conflict with or wipe out other methods on the key. maybe its all safe? i just worry about putting my keys on something i may inadvertently wipe while playing with another auth protocol setup on it
Example: we have a user set up with yubikey login for active directory. he plugs it into his home PC and runs the setup for his home PC via yubi login configuration for non-AD joined WIndows 10. What are the chances he is able to inadvertently wipe the domain info from it. Is it the same type of authentication method on the key, will the Yubi software warn that the key is used for something else and will be wiped?
admin accounts would be for the individual admins - not shared. so on termination we’d terminate their accounts, the MFA will be useless if the account tied to it is disabled or deleted…
Essentially what I’m trying to do here is not only secure AD/365 with a corporate issued key, but also encourage the users to use them for their personal stuff so they are in the habit of good security hygiene.
I’m a believer that they’ll resent being forced into using MFA a lot less if they also get the benefit of it for their personal accounts, and they’ll be more familiar with the processes involved if using it for more accounts.
Essentially i want to foster good security habits for all their online activity, because the lines these days are starting to become increasingly blurred.
Depends how you set it up. I used a certificate based auth (PIV) for AD and yubikeys as it worked well and had some inbuilt support. But there’s a limit to the number of certificates you can hold. I think newer v4/5 keys have 4+20 but the 20 are meant for retired keys.
You also have U2F and you can generally setup two OTP functions plus OAUTH. Functions depend on the yubikey you’ve got
is there a doc somewhere that explains what uses all the different auth methods the yubikey supports?
i know it supports a bunch of three letter acronyms but knowing what is used for what product or service and how they interact with each other etc seems to be difficult to find
For what you want to use each for… there’s not an exhaustive list
Windows supports PIV as does Mac and Linux with an extra package. It also supports other options , Linux can do hmac otp if you want or other methods. Gmail supports U2F as so many other aides.
Everything supports static passwords
Best option is probably to decide what you want to do when pick the option that beat fits it
Can AD use U2F? I think that’s what you want to avoid limitations on key storage. I believe pgp uses all the key slots (signing key, encryption key, etc), so you can’t use it and PIV on the same key. With U2F though, I don’t think there’s a limit to how many services you can register. It’s more like the service remembers the key instead of the key holding authentication for the service (anyone please correct me here if I’m wrong, I’m not familiar with the underlying mechanics).
Can you use pgp keys? Kind of how that’s supposed to work anyway, you have the one set of keys that acts as a passport to access or do whatever things you’re supposed to access/do.
Lol at making a bunch of Windows admins set up gpg though…
If you’re going the smart card route, you can change the management key from the default on the PIV application to prevent users from being able to accidentally overwrite corporate key material while giving them free reign on the OTP, OATH, FIDO, and OpenPGP applications.
In any case, you should probably open a support ticket. I’ve heard their technical support is superb
I didnt know this was an option. Thats interesting. I should have checked though, ive noticed they’ve been moving a lot/all of their new AD features into cloud only AD.
OK, so i’ve built a lab in HyperV and keep getting an issue that my Yubikey (plugged into the host) is “read only” from within the guest. I’m trying to do Active Directory PIV (certificate based) login setup.
Anyone using Yubikeys in this configuration? If its a limitation of Windows’. ability for pass-through of the device to a guest (only does it read only) that’s fair enough, i’ll need to start over with some real hardware. Otherwise I must be doing something wrong
Guests - All Server 2019: a DC, a CA and a server 2019 client just for testing
HyperV host - Windows 10 build 20h2
looks like hyperv only passes smart cards read only. which makes it pretty useless as a lab setup fo this. oh well. will bridge the vSwitch to another physical nic and plug in a physical machine to it to act as a client.
Confirming:
Hyper-V guests only get READ ONLY access to smart cards via the guest services offered by the host. I managed to onboard/prep a key and have it work with a physical client machine this morning.
So - you can log into a VM guest with an existing, prepared key but you can’t onboard a YubiKey from within a VM guest - at least with Hyper-V. KVM, VMware, YMMV.
So as of this morning, I’ve prepared a lab AD environment using PIV authentication. There were a few traps I encountered along the way:
If you set up your CA with cert cipher types or key lengths too long you can’t configure a smart card template as per YubiKey instructions.
Keys aren’t read/write in hyper-v guest as above
I’ll be preparing a change management req for work so if I remember I’ll list changes to AD required here as well.
OK, things you need to do, to get Yubikey PIV working:
get the PIV deployment guide for active directory “Yubikey Smart Card Deployment Guide”
have a PKI set up, if you do not have one, get that established first. for a lab, you can run through the MS CA installation wizard and just set up an AD integrated root CA (don’t bother with multi tier for lab). be sure to reference page 10 of the Yubikey guide and make sure to NOT exceed the supported certificate size or key length figures listed when configuring your CA, or you will not be able to deploy the cert template later.
Deploy the Yubikey mini driver to your machines that need local (OR RDP) login via key
Follow through page 13-14 of the document to duplicate and modify the default Windows CA template for Smartcard Logon
For test optional - configure auto-enrolment for user certificates in group policy. This is optional, for test, you can just enrol manually.
Page 15: PRIOR to deploying a cert to a key (at least for a production deployment) ensure you set and record PUK on the key with the Yubikey Manager in the PIV application section so that if your user forgets/nukes their pin you can help them reset it via PUK
Once you’ve onboarded a key and confirmed it works, you can change the user account setting in AD to “require smart card for interactive logon”. If you don’t the user will be able to use either password or key.
So, so far I have login working. Questions unanswered by the document with some answers some without answers:
Q. Can I have two yubikeys plugged in for say, a local account and an elevated (domain admin account) during normal use
A. Yes
Q. If I revoke a cert in AD, how do a re-enrol and re-deploy a new one? Will auto-enrolment re-enrol the user fairly automatically?
A. working on that
Q. What is the impact of setting up a management key in the PIV section
A. I’ve not yet messed with that.
Q. How do I delegate enrolment to IT staff for other users
A. there’s docs but I haven’t done it or read through it yet.