8:58 p.m.
I am struggling to get smartcard authentication working on RHEL7,
using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
Directory KDCs.
Has anyone actually gotten this working? If so, what behavior
differences do you see from various login mechanisms (gdm, login,
et. al.)?
Because I see *no* visual differences in any login mechanism. gdm,
login, et. al. prompt for a username/password, exactly as before.
Both after I enter the username, and after I enter the PIN (at the
"password" prompt), there is a delay while sssd pokes at the card. I
can also tell this from watching the light on the card reader blink.
But then the login fails.
I mean, these documents:
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_p...
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certifi...
…make it sound like the gdm login screen should prompt me to insert a
smartcard, or least differentiate *somehow* that smartcard
authentication is in play. Both features claim to be implemented in
sssd-1.16.4-21.el7. But I see nothing that indicates these features
are working.
If it's really the case that we have to train our users to type their
username into the "username" prompt and enter their smartcard PIN into
the "password" prompt, we can do that, but that doesn't seem to be how
it's supposed to work based on the above documents. And that's going
to seem completely horrible to users in contrast to how Windows works,
where you walk up, insert your smartcard, and the login screen
identifies you and then prompts for your PIN.
I mean, I get it that /usr/bin/login running on a virtual console
can't engage in a nifty interactive dialog like Windows does. But is
really the case that gdm is that dumb with smartcards as well?
Or am I misunderstanding how gdm+sssd+smartcard+PKINIT is supposed to
work?
I can supply (somewhat redacted) configuration files if need be, but I
have everything set correctly that I know to set:
* krb5.conf is configured correctly; I can kinit using the
smartcard+PIN.
* We use pam_sss.so in all of (password-auth, system-auth,
smartcard-auth), so no matter how a program enters the PAM stack, it
should get pam_sss.so and PKINIT.
* I touched /var/lib/sss/pubconf/pam_preauth_available into existence
and restarted sssd.
* I set enable-smartcard-authentication to true in dconf (for
org.gnome.login-screen).
* I set "pam_cert_auth = true" in the [domain/example.org] section of
/etc/sssd/sssd.conf.
* I extracted the correct certificate from my smartcard (the one that
krb5.conf is configured to find) and added it to my userCertificate
attribute in Active Directory.
* I even populated /etc/pki/nssdb with all of the same certificates
that update-ca-trust maintains, even though I'm not sure that's
necessary, as I think krb5 pkinit.so should handle that.
* I increased various sssd timeouts to work around this bug in sssd
that was derailing the nss responder:
#4103 slow smartcard interactions break sssd when PKINIT is configured
https://pagure.io/SSSD/sssd/issue/4103
I'm open to suggestions for anything that I missed.
2:25 a.m.
On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote:
I am struggling to get smartcard authentication working on RHEL7,
using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
Directory KDCs.
Has anyone actually gotten this working? If so, what behavior
differences do you see from various login mechanisms (gdm, login,
et. al.)?
I've gotten it working.
Because I see *no* visual differences in any login mechanism. gdm,
login, et. al. prompt for a username/password, exactly as before.
Both after I enter the username, and after I enter the PIN (at the
"password" prompt), there is a delay while sssd pokes at the card. I
can also tell this from watching the light on the card reader blink.
I've seen it behave both ways, and I'm not sure what the difference was.
Sometimes, the GDM login screen automatically shows the correct user when the Smart Card
is inserted; other times, I must first enter the user name before being prompted for the
PIN.
But then the login fails.
I mean, these documents:
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_p...
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certifi...
…make it sound like the gdm login screen should prompt me to insert a
smartcard, or least differentiate *somehow* that smartcard
authentication is in play. Both features claim to be implemented in
sssd-1.16.4-21.el7. But I see nothing that indicates these features
are working.
I've not seen GDM prompt for a Smart Card, but I'm also not enforcing Smart
Card-only login at this time.
If it's really the case that we have to train our users to type
their
username into the "username" prompt and enter their smartcard PIN into
the "password" prompt, we can do that, but that doesn't seem to be how
it's supposed to work based on the above documents. And that's going
to seem completely horrible to users in contrast to how Windows works,
where you walk up, insert your smartcard, and the login screen
identifies you and then prompts for your PIN.
The PIN should not be entered into the "Password" prompt. Only the prompt that
says "PIN"
I mean, I get it that /usr/bin/login running on a virtual console
can't engage in a nifty interactive dialog like Windows does. But is
really the case that gdm is that dumb with smartcards as well?
Or am I misunderstanding how gdm+sssd+smartcard+PKINIT is supposed to
work?
I can supply (somewhat redacted) configuration files if need be, but I
have everything set correctly that I know to set:
* krb5.conf is configured correctly; I can kinit using the
smartcard+PIN.
This is correct if you can type the following and are prompted for a PIN:
$ kinit username@REALM
In particular, you shouldn't have to pass any additional parameters to kinit.
Generally, the steps to make this work are to set these in krb5.conf:
[libdefaults]
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
pkinit_identities = PKCS11:
pkinit_cert_match = <EKU>msScLogin<KU>digitalSignature
[realms]
EXAMPLE.COM = {
pkinit_kdc_hostname = EXAMPLE.COM
}
In particular, the `FILE:` part is important; you can't use just a path. (You can also
use DIR:, etc.)
pkinit_kdc_hostname is needed because the AD CA generally doesn't have the
id-pkinit-san attribute on its certificate.
* We use pam_sss.so in all of (password-auth, system-auth,
smartcard-auth), so no matter how a program enters the PAM stack, it
should get pam_sss.so and PKINIT.
AFAIK, there's no way in the RHEL 7 version of sssd to enforce PKINIT at the SSSD
level, but it will perform PKINIT in the case that Smart Card auth is being performed.
* I touched /var/lib/sss/pubconf/pam_preauth_available into
existence
and restarted sssd.
There is no need to perform this step. This is performed automatically by sssd when
configured with `pam_cert_auth = True`
* I set enable-smartcard-authentication to true in dconf (for
org.gnome.login-screen).
I didn't have to change this from the default.
* I set "pam_cert_auth = true" in the [domain/example.org]
section of
/etc/sssd/sssd.conf.
This should be in the [pam] section of the sssd.conf
* I extracted the correct certificate from my smartcard (the one
that
krb5.conf is configured to find) and added it to my userCertificate
attribute in Active Directory.
This is necessary if you want to use the Smart Card for SSH authentication. I'm
unsure if it's necessary for authentication when the card is physically present at the
machine. I know it's not necessary with the latest upstream version of SSSD, but not
sure if it made it into RHEL.
* I even populated /etc/pki/nssdb with all of the same certificates
that update-ca-trust maintains, even though I'm not sure that's
necessary, as I think krb5 pkinit.so should handle that.
This is required for SSSD, but not for plain PKINIT.
I had to do this to add them to the nssdb store:
# certutil -A -n example_ca -t CT,C,C -a -d /etc/pki/nssdb -i example_ca.crt
* I increased various sssd timeouts to work around this bug in sssd
that was derailing the nss responder:
#4103 slow smartcard interactions break sssd when PKINIT is configured
https://pagure.io/SSSD/sssd/issue/4103
I'd been considering opening my own bug against pcscd (pcsc-lite?) because of the long
delays caused by accessing the card. (Seems like this could be cached.)
I'm open to suggestions for anything that I missed.
The thing that solved pkinit for me when logging in on RHEL 7 was the p11_child_timeout in
sssd.conf:
[pam]
p11_child_timeout = 90
Strangely, RHEL 8 did not require that timeout value to be set. The built-in default
value is 6 seconds, IIRC.
Hope that's helpful, and I'd be interested in hearing about any gotchas you solve
along the way.
V/r,
James Cassell
4:38 p.m.
On Sat, Oct 19, 2019 at 3:26 AM James Cassell
<fedoraproject(a)cyberpear.com> wrote:
On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote:
> I am struggling to get smartcard authentication working on RHEL7,
> using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
> Directory KDCs.
>
> Has anyone actually gotten this working? If so, what behavior
> differences do you see from various login mechanisms (gdm, login,
> et. al.)?
I've gotten it working.
> Because I see *no* visual differences in any login
> mechanism. gdm, login, et. al. prompt for a username/password,
> exactly as before. Both after I enter the username, and after I
> enter the PIN (at the "password" prompt), there is a delay while
> sssd pokes at the card. I can also tell this from watching the
> light on the card reader blink.
I've seen it behave both ways, and I'm not sure what the difference
was. Sometimes, the GDM login screen automatically shows the
correct user when the Smart Card is inserted; other times, I must
first enter the user name before being prompted for the PIN.
I've not seen GDM prompt for a Smart Card, but I'm also not
enforcing Smart Card-only login at this time.
I tried disabling password authentication, but the only change I saw
in gdm's behavior was that it skipped the "password" prompt.
> If it's really the case that we have to train our users to
type
> their username into the "username" prompt and enter their
> smartcard PIN into the "password" prompt, we can do that, but that
> doesn't seem to be how it's supposed to work based on the above
> documents. And that's going to seem completely horrible to users
> in contrast to how Windows works, where you walk up, insert your
> smartcard, and the login screen identifies you and then prompts
> for your PIN.
The PIN should not be entered into the "Password" prompt. Only the
prompt that says "PIN"
OK, good to know. I haven't seen any PIN prompts, so that tells me
gdm isn't even getting to that point in the process.
> * I touched /var/lib/sss/pubconf/pam_preauth_available into
> existence and restarted sssd.
There is no need to perform this step. This is performed
automatically by sssd when configured with `pam_cert_auth = True`
Noted.
> * I set "pam_cert_auth = true" in the
[domain/example.org] section
> of /etc/sssd/sssd.conf.
This should be in the [pam] section of the sssd.conf
Hmmm. It seemed to work for me in the [domain] section. (Or at
least, it changed the login behavior.) But I'll go back and try it in
the [pam] section.
> * I extracted the correct certificate from my smartcard (the
one
> that krb5.conf is configured to find) and added it to my
> userCertificate attribute in Active Directory.
This is necessary if you want to use the Smart Card for SSH
authentication. I'm unsure if it's necessary for authentication
when the card is physically present at the machine. I know it's not
necessary with the latest upstream version of SSSD, but not sure if
it made it into RHEL.
This feature:
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file....
…didn't make it to RHEL7, no.
We know that in order for gdm to be able to identify the user
corresponding to the inserted smartcard, sssd needs to be able to map
a smartcard to an AD user. The only way that the RHEL7 version of
sssd knows how to do that is by searching for an AD user object that
has a userCertificate attribute that matches the one on the smartcard.
Thus the requirement to populate userCertificate attributes.
BUT: if the only consequence of not populating the AD user objects
with the userCertificate attribute is that the user will need to enter
their username before entering their PIN, then we will gleefully avoid
populating our AD user objects with the userCertificate attributes:
1. It's another tedious step that has to be performed whenever we
[re]issue] a smartcard.
2. Smartcard login on Windows doesn't require the userCertificate
attribute in order to map the smartcard to a user. (Instead,
Windows extracts the CN of the smartcard certificate and matches
it to the AD user(s) who have that CN value as their
userPrincipalName attributes.) So I'm taking flak from our AD
admins who don't understand why LInux needs this step.
Assuming I can get smartcard logins working, I'll then test to see
what happens if I remove the userCertificate attribute from my AD user
object. Will doing so break smartcard logins, or will it just mean
that gdm prompts me for my username, because sssd can't figure out who
I am just from the certificate on the smartcard alone?
> * I even populated /etc/pki/nssdb with all of the same
> certificates that update-ca-trust maintains, even though I'm not
> sure that's necessary, as I think krb5 pkinit.so should handle
> that.
This is required for SSSD, but not for plain PKINIT.
Yeah, that's what I thought. But I wasn't completely sure, so I did
it anyway.
Once I get it working, I'll reset /etc/pki/nssdb back to its default
(no certificates) and test to see whether smartcard login still works.
> * I increased various sssd timeouts to work around this bug in
> sssd that was derailing the nss responder:
>
> #4103 slow smartcard interactions break sssd when PKINIT is
> configured https://pagure.io/SSSD/sssd/issue/4103
I'd been considering opening my own bug against pcscd (pcsc-lite?)
because of the long delays caused by accessing the card. (Seems
like this could be cached.)
The delays seem specific to certain reader and/or smartcard
combinations.
For example, I was testing with a different smartcard, and pcscd could
read that smartcard *much* more rapidly.
But, alas, for the specific smartcard implementation we have to use,
pcscd is *sloooooooooow*.
Nonetheless, I will poke around in upstream bug reports, and see if
this issue has come up before. Perhaps there's some way to increase
the speed.
> I'm open to suggestions for anything that I missed.
The thing that solved pkinit for me when logging in on RHEL 7 was
the p11_child_timeout in sssd.conf:
[pam]
p11_child_timeout = 90
Strangely, RHEL 8 did not require that timeout value to be set. The
built-in default value is 6 seconds, IIRC.
Sigh… I missed that one. I only have these ones:
krb5_auth_timeout: 60
ldap_network_timeout: 60
ldap_opt_timeout: 60
ldap_search_timeout: 60
I know for our reader/smartcard combination, there's no way the p11
child is going to be able to do *anything* with them in under 6
seconds.
I will add the p11_child_timeout setting an re-test.
Hope that's helpful
Indeed it was; much thanks.
and I'd be interested in hearing about any gotchas you solve
along
the way.
Red Hat's syntactically incorrect pkinit_anchors setting in
/etc/krb5.conf derailed us until I rebuilt pkinit.so with debugging
and could see what it was choking on:
syntax error in default /etc/krb5.conf file silently breaks PKINIT
https://bugzilla.redhat.com/show_bug.cgi?id=1757506
There's a subtle bug in OpenSC that breaks CoolKey-based cards using
2048-bit RSA certificates (which is what we're using):
"pkcs11-tool --test" fails with a SIPR card #1524
https://github.com/OpenSC/OpenSC/issues/1524
OpenSC 0.20.0 will have the fix, but no released version of OpenSC
does, and Red Hat hasn't backported the fix. So I had to backport the
fix myself, building local RPM packages (based on the latest RHEL7
source RPMs) that had the fix.
In general, the fact that pkinit.so provides absolutely no diagnostics
whatsoever (unless it is re-compiled with debugging flags) was the
biggest gotcha. There are multiple options that need to be set
correctly in order to get PKINIT working.
When I get this working, I'm going to write a guide for how to do it,
and specifically include links for the above gotchas.
7:53 p.m.
On Sun, Oct 20, 2019, at 5:38 PM, James Ralston wrote:
On Sat, Oct 19, 2019 at 3:26 AM James Cassell
<fedoraproject(a)cyberpear.com> wrote:
> On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote:
>
> > I am struggling to get smartcard authentication working on RHEL7,
> > using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
> > Directory KDCs.
> >
> > Has anyone actually gotten this working? If so, what behavior
> > differences do you see from various login mechanisms (gdm, login,
> > et. al.)?
>
> I've gotten it working.
>
> > Because I see *no* visual differences in any login
> > mechanism. gdm, login, et. al. prompt for a username/password,
> > exactly as before. Both after I enter the username, and after I
> > enter the PIN (at the "password" prompt), there is a delay while
> > sssd pokes at the card. I can also tell this from watching the
> > light on the card reader blink.
>
> I've seen it behave both ways, and I'm not sure what the difference
> was. Sometimes, the GDM login screen automatically shows the
> correct user when the Smart Card is inserted; other times, I must
> first enter the user name before being prompted for the PIN.
>
> I've not seen GDM prompt for a Smart Card, but I'm also not
> enforcing Smart Card-only login at this time.
I tried disabling password authentication, but the only change I saw
in gdm's behavior was that it skipped the "password" prompt.
> > If it's really the case that we have to train our users to type
> > their username into the "username" prompt and enter their
> > smartcard PIN into the "password" prompt, we can do that, but that
> > doesn't seem to be how it's supposed to work based on the above
> > documents. And that's going to seem completely horrible to users
> > in contrast to how Windows works, where you walk up, insert your
> > smartcard, and the login screen identifies you and then prompts
> > for your PIN.
>
> The PIN should not be entered into the "Password" prompt. Only the
> prompt that says "PIN"
OK, good to know. I haven't seen any PIN prompts, so that tells me
gdm isn't even getting to that point in the process.
> > * I touched /var/lib/sss/pubconf/pam_preauth_available into
> > existence and restarted sssd.
>
> There is no need to perform this step. This is performed
> automatically by sssd when configured with `pam_cert_auth = True`
Noted.
> > * I set "pam_cert_auth = true" in the [domain/example.org] section
> > of /etc/sssd/sssd.conf.
>
> This should be in the [pam] section of the sssd.conf
Hmmm. It seemed to work for me in the [domain] section. (Or at
least, it changed the login behavior.) But I'll go back and try it in
the [pam] section.
> > * I extracted the correct certificate from my smartcard (the one
> > that krb5.conf is configured to find) and added it to my
> > userCertificate attribute in Active Directory.
>
> This is necessary if you want to use the Smart Card for SSH
> authentication. I'm unsure if it's necessary for authentication
> when the card is physically present at the machine. I know it's not
> necessary with the latest upstream version of SSSD, but not sure if
> it made it into RHEL.
This feature:
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file....
…didn't make it to RHEL7, no.
/me hopes beyond hope that it gets into 7.8 :P
We know that in order for gdm to be able to identify the user
corresponding to the inserted smartcard, sssd needs to be able to map
a smartcard to an AD user. The only way that the RHEL7 version of
sssd knows how to do that is by searching for an AD user object that
has a userCertificate attribute that matches the one on the smartcard.
Thus the requirement to populate userCertificate attributes.
BUT: if the only consequence of not populating the AD user objects
with the userCertificate attribute is that the user will need to enter
their username before entering their PIN, then we will gleefully avoid
populating our AD user objects with the userCertificate attributes:
1. It's another tedious step that has to be performed whenever we
[re]issue] a smartcard.
2. Smartcard login on Windows doesn't require the userCertificate
attribute in order to map the smartcard to a user. (Instead,
Windows extracts the CN of the smartcard certificate and matches
it to the AD user(s) who have that CN value as their
userPrincipalName attributes.) So I'm taking flak from our AD
admins who don't understand why LInux needs this step.
Assuming I can get smartcard logins working, I'll then test to see
what happens if I remove the userCertificate attribute from my AD user
object. Will doing so break smartcard logins, or will it just mean
that gdm prompts me for my username, because sssd can't figure out who
I am just from the certificate on the smartcard alone?
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.
> > * I even populated /etc/pki/nssdb with all of the same
> > certificates that update-ca-trust maintains, even though I'm not
> > sure that's necessary, as I think krb5 pkinit.so should handle
> > that.
>
> This is required for SSSD, but not for plain PKINIT.
Yeah, that's what I thought. But I wasn't completely sure, so I did
it anyway.
Once I get it working, I'll reset /etc/pki/nssdb back to its default
(no certificates) and test to see whether smartcard login still works.
nssdb is likely to be required for SSH Smart Card authentication
> > * I increased various sssd timeouts to work around this bug
in
> > sssd that was derailing the nss responder:
> >
> > #4103 slow smartcard interactions break sssd when PKINIT is
> > configured https://pagure.io/SSSD/sssd/issue/4103
>
> I'd been considering opening my own bug against pcscd (pcsc-lite?)
> because of the long delays caused by accessing the card. (Seems
> like this could be cached.)
The delays seem specific to certain reader and/or smartcard
combinations.
For example, I was testing with a different smartcard, and pcscd could
read that smartcard *much* more rapidly.
But, alas, for the specific smartcard implementation we have to use,
pcscd is *sloooooooooow*.
Nonetheless, I will poke around in upstream bug reports, and see if
this issue has come up before. Perhaps there's some way to increase
the speed.
> > I'm open to suggestions for anything that I missed.
>
> The thing that solved pkinit for me when logging in on RHEL 7 was
> the p11_child_timeout in sssd.conf:
>
> [pam]
> p11_child_timeout = 90
>
> Strangely, RHEL 8 did not require that timeout value to be set. The
> built-in default value is 6 seconds, IIRC.
Sigh… I missed that one. I only have these ones:
krb5_auth_timeout: 60
ldap_network_timeout: 60
ldap_opt_timeout: 60
ldap_search_timeout: 60
I know for our reader/smartcard combination, there's no way the p11
child is going to be able to do *anything* with them in under 6
seconds.
I will add the p11_child_timeout setting an re-test.
> Hope that's helpful
Indeed it was; much thanks.
> and I'd be interested in hearing about any gotchas you solve along
> the way.
Red Hat's syntactically incorrect pkinit_anchors setting in
/etc/krb5.conf derailed us until I rebuilt pkinit.so with debugging
and could see what it was choking on:
syntax error in default /etc/krb5.conf file silently breaks PKINIT
https://bugzilla.redhat.com/show_bug.cgi?id=1757506
Awesome, thanks for the reference! I'll ask to attach that to my Support Case. (I
also wasted days on that exact issue.)
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.
The easiest way I know to do that is to install the `opensc` package then:
# pkcs11-switch coolkey
"pkcs11-tool --test" fails with a SIPR card #1524
https://github.com/OpenSC/OpenSC/issues/1524
OpenSC 0.20.0 will have the fix, but no released version of OpenSC
does, and Red Hat hasn't backported the fix. So I had to backport the
fix myself, building local RPM packages (based on the latest RHEL7
source RPMs) that had the fix.
In general, the fact that pkinit.so provides absolutely no diagnostics
whatsoever (unless it is re-compiled with debugging flags) was the
biggest gotcha. There are multiple options that need to be set
correctly in order to get PKINIT working.
Was it trivial to recompile w/ debug flags? I'm familiar w/ the likes of `fedpkg
mockbuild` for tweaking packages, but haven't looked at the source for pkinit...
When I get this working, I'm going to write a guide for how to do
it,
and specifically include links for the above gotchas.
That would be great! Once I have this fully deployed, I plan to push management to
release our related ansible roles as Open Source.
Thanks for sharing your gotchas.
V/r,
James Cassell
4:38 a.m.
On Sun, Oct 20, 2019 at 08:53:48PM -0400, James Cassell wrote:
On Sun, Oct 20, 2019, at 5:38 PM, James Ralston wrote:
> On Sat, Oct 19, 2019 at 3:26 AM James Cassell
> <fedoraproject(a)cyberpear.com> wrote:
>
> > On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote:
> >
> > > I am struggling to get smartcard authentication working on RHEL7,
> > > using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
> > > Directory KDCs.
> > >
> > > Has anyone actually gotten this working? If so, what behavior
> > > differences do you see from various login mechanisms (gdm, login,
> > > et. al.)?
> >
> > I've gotten it working.
> >
> > > Because I see *no* visual differences in any login
> > > mechanism. gdm, login, et. al. prompt for a username/password,
> > > exactly as before. Both after I enter the username, and after I
> > > enter the PIN (at the "password" prompt), there is a delay
while
> > > sssd pokes at the card. I can also tell this from watching the
> > > light on the card reader blink.
> >
> > I've seen it behave both ways, and I'm not sure what the difference
> > was. Sometimes, the GDM login screen automatically shows the
> > correct user when the Smart Card is inserted; other times, I must
> > first enter the user name before being prompted for the PIN.
> >
> > I've not seen GDM prompt for a Smart Card, but I'm also not
> > enforcing Smart Card-only login at this time.
>
> I tried disabling password authentication, but the only change I saw
> in gdm's behavior was that it skipped the "password" prompt.
>
> > > If it's really the case that we have to train our users to type
> > > their username into the "username" prompt and enter their
> > > smartcard PIN into the "password" prompt, we can do that, but
that
> > > doesn't seem to be how it's supposed to work based on the above
> > > documents. And that's going to seem completely horrible to users
> > > in contrast to how Windows works, where you walk up, insert your
> > > smartcard, and the login screen identifies you and then prompts
> > > for your PIN.
This 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. The latter should be done automatically during
the installation of the related package. About dconf, how did you add
the Smartcard authentication option?
> >
> > The PIN should not be entered into the "Password" prompt. Only the
> > prompt that says "PIN"
>
> OK, good to know. I haven't seen any PIN prompts, so that tells me
> gdm isn't even getting to that point in the process.
>
> > > * I touched /var/lib/sss/pubconf/pam_preauth_available into
> > > existence and restarted sssd.
> >
> > There is no need to perform this step. This is performed
> > automatically by sssd when configured with `pam_cert_auth = True`
>
> Noted.
>
> > > * I set "pam_cert_auth = true" in the [domain/example.org]
section
> > > of /etc/sssd/sssd.conf.
> >
> > This should be in the [pam] section of the sssd.conf
>
> Hmmm. It seemed to work for me in the [domain] section. (Or at
> least, it changed the login behavior.) But I'll go back and try it in
> the [pam] section.
>
> > > * I extracted the correct certificate from my smartcard (the one
> > > that krb5.conf is configured to find) and added it to my
> > > userCertificate attribute in Active Directory.
> >
> > This is necessary if you want to use the Smart Card for SSH
> > authentication. I'm unsure if it's necessary for authentication
> > when the card is physically present at the machine. I know it's not
> > necessary with the latest upstream version of SSSD, but not sure if
> > it made it into RHEL.
>
> This feature:
>
>
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file....
>
> …didn't make it to RHEL7, no.
>
/me hopes beyond hope that it gets into 7.8 :P
> We know that in order for gdm to be able to identify the user
> corresponding to the inserted smartcard, sssd needs to be able to map
> a smartcard to an AD user. The only way that the RHEL7 version of
> sssd knows how to do that is by searching for an AD user object that
> has a userCertificate attribute that matches the one on the smartcard.
> Thus the requirement to populate userCertificate attributes.
>
> BUT: if the only consequence of not populating the AD user objects
> with the userCertificate attribute is that the user will need to enter
> their username before entering their PIN, then we will gleefully avoid
> populating our AD user objects with the userCertificate attributes:
>
> 1. It's another tedious step that has to be performed whenever we
> [re]issue] a smartcard.
>
> 2. Smartcard login on Windows doesn't require the userCertificate
> attribute in order to map the smartcard to a user. (Instead,
> Windows extracts the CN of the smartcard certificate and matches
> it to the AD user(s) who have that CN value as their
> userPrincipalName attributes.) So I'm taking flak from our AD
> admins who don't understand why LInux needs this step.
>
> Assuming I can get smartcard logins working, I'll then test to see
> what happens if I remove the userCertificate attribute from my AD user
> object. Will doing so break smartcard logins, or will it just mean
> that gdm prompts me for my username, because sssd can't figure out who
> I am just from the certificate on the smartcard alone?
>
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.
> > > * I even populated /etc/pki/nssdb with all of the same
> > > certificates that update-ca-trust maintains, even though I'm not
> > > sure that's necessary, as I think krb5 pkinit.so should handle
> > > that.
> >
> > This is required for SSSD, but not for plain PKINIT.
>
> Yeah, that's what I thought. But I wasn't completely sure, so I did
> it anyway.
>
> Once I get it working, I'll reset /etc/pki/nssdb back to its default
> (no certificates) and test to see whether smartcard login still works.
>
nssdb is likely to be required for SSH Smart Card authentication
/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.
> > > * I increased various sssd timeouts to work around this bug in
> > > sssd that was derailing the nss responder:
> > >
> > > #4103 slow smartcard interactions break sssd when PKINIT is
> > > configured https://pagure.io/SSSD/sssd/issue/4103
> >
> > I'd been considering opening my own bug against pcscd (pcsc-lite?)
> > because of the long delays caused by accessing the card. (Seems
> > like this could be cached.)
I commented in the pagure ticket and mentioned a work-around.
>
> The delays seem specific to certain reader and/or smartcard
> combinations.
>
> For example, I was testing with a different smartcard, and pcscd could
> read that smartcard *much* more rapidly.
>
> But, alas, for the specific smartcard implementation we have to use,
> pcscd is *sloooooooooow*.
>
> Nonetheless, I will poke around in upstream bug reports, and see if
> this issue has come up before. Perhaps there's some way to increase
> the speed.
>
> > > I'm open to suggestions for anything that I missed.
> >
> > The thing that solved pkinit for me when logging in on RHEL 7 was
> > the p11_child_timeout in sssd.conf:
> >
> > [pam]
> > p11_child_timeout = 90
> >
> > Strangely, RHEL 8 did not require that timeout value to be set. The
> > built-in default value is 6 seconds, IIRC.
The default value is 10. In RHEL8 p11-kit is used by SSSD to access the
Smartcard while in RHEL7 NSS is used here as well. This might cause a
bit less overhead with your setup and in the result a bit faster
operation.
>
> Sigh… I missed that one. I only have these ones:
>
> krb5_auth_timeout: 60
> ldap_network_timeout: 60
> ldap_opt_timeout: 60
> ldap_search_timeout: 60
>
> I know for our reader/smartcard combination, there's no way the p11
> child is going to be able to do *anything* with them in under 6
> seconds.
>
> I will add the p11_child_timeout setting an re-test.
>
> > Hope that's helpful
>
> Indeed it was; much thanks.
>
> > and I'd be interested in hearing about any gotchas you solve along
> > the way.
>
> Red Hat's syntactically incorrect pkinit_anchors setting in
> /etc/krb5.conf derailed us until I rebuilt pkinit.so with debugging
> and could see what it was choking on:
>
> syntax error in default /etc/krb5.conf file silently breaks PKINIT
> https://bugzilla.redhat.com/show_bug.cgi?id=1757506
>
Awesome, thanks for the reference! I'll ask to attach that to my Support Case. (I
also wasted days on that exact issue.)
> 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.
The easiest way I know to do that is to install the `opensc` package then:
# pkcs11-switch coolkey
> "pkcs11-tool --test" fails with a SIPR card #1524
> https://github.com/OpenSC/OpenSC/issues/1524
>
> OpenSC 0.20.0 will have the fix, but no released version of OpenSC
> does, and Red Hat hasn't backported the fix. So I had to backport the
> fix myself, building local RPM packages (based on the latest RHEL7
> source RPMs) that had the fix.
>
> In general, the fact that pkinit.so provides absolutely no diagnostics
> whatsoever (unless it is re-compiled with debugging flags) was the
> biggest gotcha. There are multiple options that need to be set
> correctly in order to get PKINIT working.
>
Was it trivial to recompile w/ debug flags? I'm familiar w/ the likes of `fedpkg
mockbuild` for tweaking packages, but haven't looked at the source for pkinit...
Please find attached a patch for this.
> When I get this working, I'm going to write a guide for how
to do it,
> and specifically include links for the above gotchas.
That would be great! Once I have this fully deployed, I plan to push management to
release our related ansible roles as Open Source.
Thank you both for helping to improve the documentation about Smartcard
authentication with real-world examples.
bye,
Sumit
Thanks for sharing your gotchas.
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...
12:16 p.m.
On Sun, Oct 20, 2019 at 8:54 PM James Cassell
<fedoraproject(a)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?
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.)
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
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.
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?
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.
On Mon, Oct 21, 2019 at 5:39 AM Sumit Bose <sbose(a)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:
$ 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?
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 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.
3:24 p.m.
On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
On Sun, Oct 20, 2019 at 8:54 PM James Cassell
<fedoraproject(a)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 <sbose(a)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
3:41 p.m.
On Mon, Oct 21, 2019 at 4:25 PM James Cassell
<fedoraproject(a)cyberpear.com> wrote:
On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
> 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.
Ah; ok.
We don't care about this, because with PKINIT login, the user
obtains a Kerberos TGT, and that TGT permits gssapi-with-mic
authentication.
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?
(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.
Yes, I'm using opensc [in nssdb]. I only referenced coolkey
since
you said your cards were coolkey-based.
Understood.
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.
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.
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.
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…
7:27 p.m.
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.
> 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
9:02 a.m.
New subject: best way to check if a host is in a net group
I need to support netgroup checks in a service, written in C. I’m asking the SSSD list
because we’re using SSSD, which means that net group operations are routed to the SSSD
provider.
I found that innetgr doesn’t work if there are nested net groups. The man page doesn’t
suggest that this would happen, though various online discussions seem to suggest it. As
far as I can tell, using the usual libc routines, I’d have to do a recursive enumeration
of the netgroup. This seems pretty silly, since the host's memberOf attribute shows
what net groups it’s a member of, whether direct or indirect. You could also enumerate
using the compat tree, which lets a single LDAP query get all members of the netgroup.
For the moment I’m doing LDAP operations. My application already needs to do
GSSAPI-authenticated LDAP operations, so I have an LDAP connection already. A netgroup
check require two queries, which could reasonably be cached. Lookup the netgroup by name
to find the unique ID. Look up the host and see if the unique ID matches any memberOf
attributes.
But not all applications would be set up so this is easy. Is there a reasonable way to
check netgroup membership using normal libc calls?
7:50 a.m.
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...
8:03 a.m.
New subject: best way to check if a host is in a net group
On Thu, Oct 31, 2019 at 02:02:51PM +0000, Charles Hedrick wrote:
I need to support netgroup checks in a service, written in C. I’m
asking the SSSD list because we’re using SSSD, which means that net group operations are
routed to the SSSD provider.
I found that innetgr doesn’t work if there are nested net groups. The man page doesn’t
suggest that this would happen, though various online discussions seem to suggest it. As
far as I can tell, using the usual libc routines, I’d have to do a recursive enumeration
of the netgroup. This seems pretty silly, since the host's memberOf attribute shows
what net groups it’s a member of, whether direct or indirect. You could also enumerate
using the compat tree, which lets a single LDAP query get all members of the netgroup.
Hi,
it would be good if you can share some logs which covered the failed
attempt. Iirc nested netgroups are handled by SSSD and glibc together.
I.e. SSSD will not resolve a nested netgroup automatically but just
returns the name and the glibc ask for the members of the nested group
if needed.
bye,
Sumit
For the moment I’m doing LDAP operations. My application already needs to do
GSSAPI-authenticated LDAP operations, so I have an LDAP connection already. A netgroup
check require two queries, which could reasonably be cached. Lookup the netgroup by name
to find the unique ID. Look up the host and see if the unique ID matches any memberOf
attributes.
But not all applications would be set up so this is easy. Is there a reasonable way to
check netgroup membership using normal libc calls?
_______________________________________________
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...
10:17 a.m.
New subject: best way to check if a host is in a net group
test,c
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
printf("%d\n", innetgr(argv[1], argv[2], NULL, NULL));
}
---------------------
[hedrick@krb2 credserv]$ ./test lcsrcf ilab1.cs.rutgers.edu
0
[hedrick@krb2 credserv]$ ipa host-show ilab1.cs.rutgers.edu
Host name: ilab1.cs.rutgers.edu
Principal name: host/ilab1.cs.rutgers.edu(a)CS.RUTGERS.EDU
Principal alias: host/ilab1.cs.rutgers.edu(a)CS.RUTGERS.EDU
SSH public key fingerprint: SHA256:XQelZD+3XV8yJTUQCU277t3Tsfin3JXFZWOXgBwlpk0
(ecdsa-sha2-nistp256), SHA256:viELfgjJE7+GXq+QDLcW3XUBRZcaiZcMOpaTXvPo/I0 (ssh-
ed25519), SHA256:MjIvgUUtUYmjohS2fCJ5NIgn6laFKSLttWYnEfN0KYY
(ssh-rsa)
Password: False
Member of netgroups: dcsilab_gpuservers__1, working-hosts, gradpool,
research-user-maint
Indirect Member of netgroup: dcsilab, dcsilab_clients, lcsrcluster, lcsrcf, dcs,
dcsilab_gpuservers
Keytab: True
Managed by: ilab1.cs.rutgers.edu
[hedrick@krb2 credserv]$ ./test dcsilab_clients ilab1.cs.rutgers.edu
1
—————————————
I’m doing this on a test kerberos server, which makes the logs easier to look at. It’s
centos 8. I walked up the hierarchy. The first place it failed was netgroup dcs. Here’s
the queries it made:
[04/Nov/2019:10:27:08.092994997 -0500] conn=22700 op=14 SRCH
base="cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu" scope=2
filter="(&(cn=dcs)(objectClass=ipaNisNetgroup))"\
attrs="objectClass cn member memberOf memberUser memberHost externalHost
nisDomainName ipaUniqueID"
[04/Nov/2019:10:27:08.093756954 -0500] conn=22700 op=14 RESULT err=0 tag=101 nentries=1
etime=0.0000917908 notes=P pr_idx=0 pr_cookie=-1
[04/Nov/2019:10:27:08.094390316 -0500] conn=22700 op=15 SRCH
base="cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu" scope=2
filter="(&(|(memberOf=ipaUniqueID=60eeb708-c407-\
11e7-baa3-000c29dbd083,cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu))(objectClass=ipaNisNetgroup))"
attrs="objectClass cn member memberOf memberUser memberHost externalH\
ost nisDomainName ipaUniqueID"
[04/Nov/2019:10:27:08.108564311 -0500] conn=22700 op=15 RESULT err=0 tag=101 nentries=48
etime=0.0014740764 notes=P pr_idx=0 pr_cookie=-1
[04/Nov/2019:10:27:08.116836919 -0500] conn=22700 op=16 SRCH
base="cn=accounts,dc=cs,dc=rutgers,dc=edu" scope=2
filter="(&(|(memberOf=ipaUniqueID=60eeb708-c407-1\
1e7-baa3-000c29dbd083,cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu))(objectClass=posixAccount))"
attrs="uid memberOf objectClass"
[04/Nov/2019:10:27:08.117217428 -0500] conn=22700 op=16 RESULT err=0 tag=101 nentries=0
etime=0.0008600383 notes=P pr_idx=0 pr_cookie=-1
[04/Nov/2019:10:27:08.117542516 -0500] conn=22700 op=17 SRCH
base="cn=accounts,dc=cs,dc=rutgers,dc=edu" scope=2
filter="(&(|(memberOf=ipaUniqueID=60eeb708-c407-1\
1e7-baa3-000c29dbd083,cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu))(objectClass=ipaIDObject)(objectClass=posixAccount))"
attrs="uid memberOf objectClass"
[04/Nov/2019:10:27:08.117684401 -0500] conn=22700 op=17 RESULT err=0 tag=101 nentries=0
etime=0.0000418212 notes=P pr_idx=0 pr_cookie=-1
[04/Nov/2019:10:27:08.118033435 -0500] conn=22700 op=18 SRCH
base="cn=accounts,dc=cs,dc=rutgers,dc=edu" scope=2
filter="(&(|(memberOf=ipaUniqueID=60eeb708-c407-1\
1e7-baa3-000c29dbd083,cn=ng,cn=alt,dc=cs,dc=rutgers,dc=edu))(objectClass=ipaHost))"
attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID"
[04/Nov/2019:10:27:08.189687425 -0500] conn=22700 op=18 RESULT err=0 tag=101 nentries=172
etime=0.0071957440 notes=P pr_idx=0 pr_cookie=-1
Let me interpret that.
Look up netgropu dcs to find uniqueID
Look for all netgroups, users, ??, hosts that are members of the uniqueID
The last query returned 172 hosts. I tried the query manually and got 172 hosts as well.
ilab1.cs.rutgers.edu was one of them. I would have expected it to return yes, but it
returned 0.
If I check the next level down in the hierarchy, I get success.
I’m going to email you the SSSD log file separately, as I’m not sure whether there’s
anteing in it that shouldn’t be public.
On Nov 1, 2019, at 9:03 AM, Sumit Bose <sbose(a)redhat.com>
wrote:
On Thu, Oct 31, 2019 at 02:02:51PM +0000, Charles Hedrick wrote:
> I need to support netgroup checks in a service, written in C. I’m asking the SSSD
list because we’re using SSSD, which means that net group operations are routed to the
SSSD provider.
>
> I found that innetgr doesn’t work if there are nested net groups. The man page
doesn’t suggest that this would happen, though various online discussions seem to suggest
it. As far as I can tell, using the usual libc routines, I’d have to do a recursive
enumeration of the netgroup. This seems pretty silly, since the host's memberOf
attribute shows what net groups it’s a member of, whether direct or indirect. You could
also enumerate using the compat tree, which lets a single LDAP query get all members of
the netgroup.
Hi,
it would be good if you can share some logs which covered the failed
attempt. Iirc nested netgroups are handled by SSSD and glibc together.
I.e. SSSD will not resolve a nested netgroup automatically but just
returns the name and the glibc ask for the members of the nested group
if needed.
bye,
Sumit
>
> For the moment I’m doing LDAP operations. My application already needs to do
GSSAPI-authenticated LDAP operations, so I have an LDAP connection already. A netgroup
check require two queries, which could reasonably be cached. Lookup the netgroup by name
to find the unique ID. Look up the host and see if the unique ID matches any memberOf
attributes.
>
> But not all applications would be set up so this is easy. Is there a reasonable way
to check netgroup membership using normal libc calls?
>
>
> _______________________________________________
> 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...
_______________________________________________
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...
7:21 p.m.
On Fri, Nov 1, 2019, at 8:50 AM, Sumit Bose wrote:
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:
> > > 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.
I tried it out, and it works pretty well. I ended up doing it with `modutil` instead of
creating a symlink so that it could be deleted by modutil if it were to become necessary:
# modutil -dbdir /etc/pki/nssdb/ -add 'Root Certs' -libfile
/usr/lib64/libnssckbi.so
(see below for disabling the "Default Trust" certificates an leaving only the
"System Trust" certs.)
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.
Thanks for the push to make it more secure!
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.
You can only add the system-customized certificates (aka "System Trust") to the
nssdb by disabling the "Default Trust" store:
# modutil -dbdir /etc/pki/nssdb/ -disable 'Root Certs' -slot
/usr/share/pki/ca-trust-source
You can then verify that only your custom Root Certs are trusted:
# certutil -L -d /etc/pki/nssdb/ -h all
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.
In effect, with SSSD-AD connection on RHEL 7, it doesn't matter since you need the
userCertificate attribute and always match the full cert. (I've opened a Support Case
to request the certmap backport to RHEL 7, per this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1736845 )
V/r,
James Cassell
805
days inactive
822
days old
sssd-users@lists.fedorahosted.org
13 comments
4 participants
participants (4)
-
Charles Hedrick -
James Cassell -
James Ralston -
Sumit Bose