Hi Dave,
The use case is a “collaboration environment.” Some small subset of USDA’s tens of thousands of employees are engaged in research with external parties. The
collaboration environment, being exposed to external actors, does not have contact with the government Active Directory server, and likely never will. This external environment must support registered Win/Linux/Mac clients, as well as connection to registered
devices from unregistered devices. The overarching goal is “convenience-oriented” in that we are trying to avoid creating new credentials/passwords for users of the environment to (mis)manage and remember(forget). Existing PIV credentials are envisioned to
cover the fraction of users who are employees, due largely to the fact that connectivity to AD is not necessary. External parties will likely be issued a username/password.
My test system is Fedora 21. The document you reference is how I started. The document’s reliance on coolkey exposed the fact that the Coolkey middleware does
not read the standard issue USDA LincPass PIV smartcard correctly. Replacing coolkey with OpenSC middleware allows me to inspect certificates. Nominal playing with pam_pkcs11 has “smart-card enabled” the “sudo” function on my test box. I do not currently understand
how pam_pkcs11 relates to a graphical login manager. I was under the impression that ESC supplied the GUI login component, and ESC apparently is hardwired to Coolkey.
I am currently setting up an MIT Kerberos server with PKINIT to get a TGT based on a PIV authentication for basic Kerberos SSO. As I understand it, pam_pkcs11
can be instructed to leverage such an infrastructure. However, as I understand it, a mixed Win/Linux environment is best served with Active Directory hosting users and Win clients, FreeIPA/IdM hosting Linux clients with FreeIPA/IdM set up to trust AD. If this
is the case, it is likely PIV authentication will need to be directed against a separate, disconnected “collaboration” AD instance, and I will need to repeat the MIT Kerberos effort with this AD. I haven’t really heard much about special purpose Mac domain
controllers. I assume they’re Linuxy enough that FreeIPA/IdM is more appropriate than AD.
Criticisms are welcome. I’ve really never done anything like this before and I’ve wished more than once that our professionals would step up and address this
need. Seems unlikely. The obvious shortcoming of my plan is that employees either do not have passwords at all, or they have another password to manage, as syncing the collaboration AD with the corporate AD is just as out of the question as exposing AD.
Bryce
From: Dave Sirrine [mailto:dsirrine@redhat.com]
Sent: Thursday, May 21, 2015 8:15 AM
To: John Magne
Cc: Nordgren, Bryce L -FS; pki-users@redhat.com
Subject: Re: [Pki-users] ESC doesn't recognize smartcard / standalone operation?
Bryce,
To piggyback on what Jack was saying, I'd like to confirm your usecase that you're only using the cards to authenticate into a system. Can you confirm the cards you're using and what OS you're trying to enable?
This is a pretty solid doc on how to do this: https://docs.fedoraproject.org/en-US/Fedora//html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html
I would recommend looking more deeply into pam_pkcs11 as it provides several mechanisms by which you can authenticate, so picking the right one for you may take some reading. Happy to help!