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(a)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-Sec...
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!
________________________________
From: "John Magne" <jmagne@redhat.com<mailto:jmagne@redhat.com>>
To: "Bryce L Nordgren -FS"
<bnordgren@fs.fed.us<mailto:bnordgren@fs.fed.us>>
Cc: pki-users@redhat.com<mailto:pki-users@redhat.com>
Sent: Monday, May 18, 2015 1:03:45 PM
Subject: Re: [Pki-users] ESC doesn't recognize smartcard / standalone operation?
Bryce:
I would imagine that the smart card manager relies upon coolkey to recognize cards.
As per your other question, I think you are fine. The whole TMS system ESC/TPS is used
to
provision cards with the coolkey applet. For other types of cards it will do nothing but
display some minor information about the token.
----- Original Message -----
From: "Bryce L Nordgren -FS"
<bnordgren@fs.fed.us<mailto:bnordgren@fs.fed.us>>
To: pki-users@redhat.com<mailto:pki-users@redhat.com>
Sent: Saturday, May 16, 2015 3:03:17 PM
Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation?
My system is to the point where command line interaction with the smart card
behaves as expected, as long as I use the OpenSC middleware to pam_pkcs11,
and not coolkey. Using pklogin_finder asks for the PIN, verifies the
certificates, and maps the user to a local system account. System details in
previous thread:
https://www.redhat.com/archives/pki-users/2015-April/msg00041.html
My expectation was that the “smart card manager” should pop up when the card
is inserted. It doesn’t. I can type “esc” at the command line, and it says
“No Cards Present” with everything greyed out. Likewise, inserting the smart
card at the login prompt does nothing. There _ is _ an “./escd” process
running. Is ESC hardwired to use coolkey, which can’t read my card? How can
I debug this?
Final question: Am I correct to assume that my situation does not call for a
TPS, TKS, or even a CA? I must not touch the info on these smart cards:
Never format, never issue certs, never save, never change. My machines just
need to respect a totally external PKI infrastructure: ask for PIN, verify
cert against the CA bundle, and start a login session. For any of the things
I would need a PKI infrastructure for, I need to make an appointment at a
GSA Credentialing Center, then physically show up with two forms of ID in
hand.
Many thanks for your helpful advice!
Bryce
_______________________________________________
Pki-users mailing list
Pki-users@redhat.com<mailto:Pki-users@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-users
_______________________________________________
Pki-users mailing list
Pki-users@redhat.com<mailto:Pki-users@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-users