On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
> On Sun, Oct 20, 2019 at 8:54 PM James Cassell
> <fedoraproj...@cyberpear.com> wrote:
> 
> > Even if local authentication works w/o the userCertificate
> > attribute, SSH authentication using the Smart Card inherently
> > requires the userCertificate attribute because the certificate is
> > not sent over the SSH session.
> 
> When you say "SSH authentication using the Smart Card", what exactly
> do you mean?
> 

I mean using the private key on the Smart Card as the SSH private key.  SSSD 
will convert the userCertificate into SSH public keys for consumption by 
openssh.

> If you mean being able to ssh to another host after one has logged in,
> we don't care about that, because we use gssapi-with-mic/gssapi-keyex
> authentication, which bypasses the PAM auth stack entirely.
> 
> A use case we would like to be able to make work is the ability for
> Windows users to ssh into Linux hosts. But we expect we will be
> unable to get that to work, because:
> 
> 1) There is no Windows SSH client implementation that we know of that
>  can both perform gssapi-with-mic/gssapi-keyex *and* delegate the
>  Kerberos credentials. For example, PuTTY can do the former, but
>  we've never been able to get it to do the latter, which means that
>  if the user logs in from Windows using PuTTY, they will have no
>  home directory, because we use autofs-mounted NFSv4 home
>  directories with auth=krb5p. (No TGT, no home directory.)
> 

PuTTY can do this ticket forwarding.  The limiting factor is convincing the 
Active Directory team (or the security team) to enable the checkbox "Trust this 
computer for delegation to any service (Kerberos only)" -- there is also an 
adcli command line arg to set this option on Computer Account creation, but 
I've not tried setting it with adcli.  I've gotten this working for the subset 
of machines for which InfoSec approved using the "Trust this computer for 
delegation to any service (Kerberos only)" checkbox.

(Side note: is there a good guide to setting up NFSv4 w/ auth=krb5p?  I've been 
wanting to do this instead of forcing cifs/samba into its place... virtually 
every NFS guide I've found left things cleartext.)

> 2) I have no idea if a Windows SSH client exists that can proxy the
>  smartcard protocol, as la p11-kit:
> 
>  https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html
> 

Yeah, I'd be interesting in something like that, as well.

Theoretically, I could write a (opensc?) plugin/driver that combines a 
forwarded ssh-agent with a userCertificate from AD/sssd and expose that as a 
Smart Card, but I'm not sure if that could run within the PAM session, or only 
afterwards...  I briefly looked at using the initial SSH key verification to do 
a pkinit (without any agent forwarding), but it looks like its signature 
structure is too strict to leverage as a pkinit attempt.

> > nssdb is likely to be required for SSH Smart Card authentication
> 
> Again, I don't think we care about this.
> 
> > > There's a subtle bug in OpenSC that breaks CoolKey-based cards
> > > using 2048-bit RSA certificates (which is what we're using):
> >
> > aha! Did you add the coolkey driver to the nssdb? That could be
> > your issue.
> 
> No, I didn't, because I saw nothing in any documentation that stated
> this was necessary.
> 
> > The easiest way I know to do that is to install the `opensc` package
> > then:
> >
> > # pkcs11-switch coolkey
> 
> opensc should be used instead of coolkey, as coolkey is deprecated in
> RHEL7, and has been removed from RHEL8 entirely.
> 

Yes, I'm using opensc.  I only referenced coolkey since you said your cards 
were coolkey-based.

> I can't test in our production environment at the moment, but I have a
> test environment that is configured as close to our production
> environment as I can make it, and in our test environment:
> 
> $ pkcs11-switch; echo EOF
> 
> EOF
> 
> So, no, /etc/pki/nssdb is not configured to use a PKCS#11 module at
> all.
> 
> $ pkcs11-switch opensc; echo EOF
> 
> WARNING: Performing this operation while the browser is running could cause
> corruption of your security databases. If the browser is currently running,
> you should exit browser before continuing this operation. Type
> 'q <enter>' to abort, or <enter> to continue:
> 
> Module "OpenSC PKCS #11 Module" added to database.
> ERROR: Failed to delete module "CoolKey PKCS #11 Module".
> EOF
> 
> $ pkcs11-switch; echo EOF
> opensc
> EOF
> 
> And, lo and behold, in the test environment gdm now detects a
> smartcard insertion and prompts for the pin.
> 
> (In our test environment, PKINIT fails because our AD KDCs aren't
> properly configured for it, so I can't be sure this is the last hurdle
> until I replicate this to our production environment.)
> 
> I still can't get /usr/bin/login on a virtual console to correctly
> perform smartcard authentication, though. Have you managed to get
> that working?
> 

I was also able to get this working at the console.  I didn't do anything 
special for the console; it just worked once the GUI was working.

> > was it trivial to recompile [pkinit] w/ debug flags?
> 
> Yes. I've attached the two patches I created. Apply them against the
> latest upstream c7 branch:
> 
> $ git clone https://git.centos.org/git/rpms/krb5.git
> $ git clone https://git.centos.org/git/centos-git-common.git
> 
> …then mockbuild as usual.
> 
> WARNING: we found that installing the resulting krb5 packages with
> debugging enabled will *break* authentication. Only install the
> debugging packages locally while you are testing kinit, and "yum
> downgrade" back to the non-debugging packages immediately after you
> are done.
> 

Thanks!


> On Mon, Oct 21, 2019 at 5:39 AM Sumit Bose <sb...@redhat.com> wrote:
> 
> > This [smartcard prompting] is a feature of GDM which requires the
> > dconf setting as you mentioned before and that the PKCS#11 module
> > (OpenSC or Coolkey) is added to /etc/pki/nssdb.
> 
> Yes, I realize that now. But this requirement is documented nowhere
> that I encountered it.
> 
> > The latter should be done automatically during the installation of
> > the related package.
> 
> No %post script on the system calls pkcs11-switch:
> 
> $ rpm -qa --scripts | grep pkcs11-switch
> 
> That includes opensc:
> 

This is something I've always had to do manually, and I've always done it via:

# pkcs11-switch opensc


> $ rpm -q --scripts opensc
> postinstall program: /sbin/ldconfig
> postuninstall program: /sbin/ldconfig
> 
> Not a single document I could find anywhere on gnome.org mentions this
> requirement, either.
> 
> If something was supposed to automatically perform this step for me, I
> don't know what it is.
> 
> > About dconf, how did you add the Smartcard authentication option?
> 
> We maintain dconf settings via Puppet.
> 
> But as James Cassell noted, it's the default, anyway.
> 
> > /etc/pki/nssdb on RHEL7 (or /etc/sssd/pki/sssd_auth_ca_db.pem on
> > RHEL8) should contain the CA certificates needed to verify the user
> > certificate.
> 
> Is this necessary for PKINIT authentication? Or just for SSH
> authentication?
> 

SSSD can do Smart Card authentication without pkinit.  To test it out, just 
remove the krb5-pkinit package.  In that case, only the nssdb is consulted and 
pkinit_anchors is irrelevant.

I'm not sure whether SSSD does its own Smart Card authentication prior to 
attempting pkinit, but it wouldn't surprise me as before I'd gotten pkinit 
working via the timeout tweaks, I'd still be allowed to logon after the pkinit 
attempts timed out (after 5 tries, I think is what sssd was doing internally.)

> We would like to avoid having to do this, because update-ca-trust(8)
> does not maintain /etc/pki/nssdb, which means we will have to come up
> with a mechanism to maintain /etc/pki/nssdb automatically on our
> hosts.
> 
> (If we can't automate it, we don't do it.)
> 

I'm in a similar situation... hoping to not write my own nssdb ansible role, 
but I'll probably need to write one since I didn't see a good existing one.

> > I commented in the pagure ticket and mentioned a work-around.
> 
> I saw; thanks. I'll respond in the ticket.
> 
> > Thank you both for helping to improve the documentation about
> > Smartcard authentication with real-world examples.
> 
> You're welcome.
> 
> With the rise of multi-factor authentication (MFA) solutions like
> Google Authenticator and Duo, using smartcards for MFA is clearly on
> the decline. (And it was never that popular to begin with.)
> 
> But, alas, there are some environments where smartcard MFA is
> mandated. So hopefully documenting how to get this to work will be
> useful to others.
> 

It's certainly not going away anytime soon for companies who have government, 
and especially DoD, contracts.


V/r,
James Cassell
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

Reply via email to