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_pkin... https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certificat...
…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.
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_pkin... https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certificat...
…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
On Sat, Oct 19, 2019 at 3:26 AM James Cassell fedoraproject@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.htm...
…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.
On Sun, Oct 20, 2019, at 5:38 PM, James Ralston wrote:
On Sat, Oct 19, 2019 at 3:26 AM James Cassell fedoraproject@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.htm...
…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:
It's another tedious step that has to be performed whenever we [re]issue] a smartcard.
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: 60I 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
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@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.htm...
…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:
It's another tedious step that has to be performed whenever we [re]issue] a smartcard.
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: 60I 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Sun, Oct 20, 2019 at 8:54 PM James Cassell fedoraproject@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@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.
On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
On Sun, Oct 20, 2019 at 8:54 PM James Cassell fedoraproject@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:
- 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.)
- 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@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
On Mon, Oct 21, 2019 at 4:25 PM James Cassell fedoraproject@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…
On Fri, Oct 25, 2019, at 4:41 PM, James Ralston wrote:
On Mon, Oct 21, 2019 at 4:25 PM James Cassell fedoraproject@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
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?
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
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@CS.RUTGERS.EDU Principal alias: host/ilab1.cs.rutgers.edu@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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
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@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
sssd-users@lists.fedorahosted.org
-
Charles Hedrick -
James Cassell -
James Ralston -
Sumit Bose