On Fri, Oct 25, 2019 at 08:27:33PM -0400, James Cassell wrote:
On Fri, Oct 25, 2019, at 4:41 PM, James Ralston wrote:
> On Mon, Oct 21, 2019 at 4:25 PM James Cassell
> <fedoraproject(a)cyberpear.com> wrote:
> > 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.
>
> Interesting. Is this a setting on the computer object of the target
> host, or on the (Windows) client where PuTTY is being executed?
>
This is a setting on each Computer object. Delegation is only allowed when connection to
machines that have it set, so from my Windows workstation, delegation would work when
connecting to some machines but not others depending on the setting for each target
machine. Linux doesn't seem to honor the setting, so you can delegate anywhere with
`ssh -K`
> > (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.)
>
> I wasn't able to find a good guide; we had to puzzle out the
> configuration ourselves.
>
> I can try to write up a guide for that (in my copious free time, ha),
> but in the meantime, shoot me off-list mail if you have specific
> questions.
>
Thanks for the offer. I know how it goes with free time...
> > I was also able to get this [smartcard login] working at the
> > console. I didn't do anything special for the console; it just
> > worked once the GUI was working.
>
> I've been able to get /usr/bin/login to prompt for the username/PIN,
> but it still fails, even after I enter the correct PIN (that works in
> gdm).
>
> This might be a PAM stack configuration issue, though. I'll have to
> dig into it further.
>
Last I tested this, I think I was using pam_sss solely, not also pam_pkcs11, which is
required if you need to enforce smart card login at the machine level (rather than
globally in AD.)
> > 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 figured out a way to avoid needing to maintain certificates in
> /etc/pki/nssdb. You only need to do these two things:
>
> $ pkcs11-switch opensc
> $ ln -s /usr/lib64/libnssckbi.so /etc/pki/nssdb/
>
> As long as alternatives is using p11-kit-trust.so:
>
> $ alternatives --display libnssckbi.so.x86_64
> libnssckbi.so.x86_64 - status is auto.
> link currently points to /usr/lib64/pkcs11/p11-kit-trust.so
> /usr/lib64/pkcs11/p11-kit-trust.so - priority 30
> /usr/lib64/nss/libnssckbi.so - priority 10
> Current `best' version is /usr/lib64/pkcs11/p11-kit-trust.so.
>
> …then p11-kit-trust.so will automatically shim the certificate trust
> database maintained by update-ca-trust(8) into NSSDB.
>
Awesome, that sounds like a huge time saver! I'm going to try that next week.
Hi,
while this might be a time saver and helps to store the same CA
certificate into various different places I'd like to add a word of
caution here.
When using certificate mapping and matching rules anyone can create a
certificate which matches the rules and matches to any given user. This
means only the CA signature can assure that is really issued by the
expected CA. The system-wide CA database will contain a wide range of CA
certificates mostly to make sure that web-browsing with https works
without much issue. Many of the CA from the system-wide database have
strict procedures and policies to make sure only properly justified
certificates are issued. But you should consider if you would really
trust all those CAs to not issue a fake sub-CA certificate which then ca
be used to create a certificate with allows authentication to your
system.
Please note this is only important if not the full certificate is used
for mapping to the user. Since the full certificate contains the key and
the signature of the CA it cannot be faked. Only if you use single
components from the certificate like e.g. a stored Kerberos principal,
you should take care of the list of trusted CAs.
bye,
Sumit
> > It's [smartcard logins] certainly not going away anytime soon for
> > companies who have government, and especially DoD, contracts.
>
> Alas, yes.
>
> I did finally get full sssd PKINIT logins working with gdm, BTW.
>
Congrats!
> Thanks to you (and you, Sumit) for your assistance; it was invaluable.
>
> Next step: to write a guide for this and throw it up somewhere (GitHub
> or Pagure) so that others can contribute and expand it…
That would be great!
V/r,
James Cassell
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...