[SSSD-users] Re: sssd PKINIT smartcard auth on RHEL7?

[James Cassell]

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
> > >  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 mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org

[SSSD-users] Re: sssd - ssh and ticket renewal

[Charles Hedrick]

On Nov 4, 2019, at 11:48 AM, Sumit Bose 
mailto:sb...@redhat.com>> wrote:

Is my assumption that one should be able to ssh to a server and have that 
server refresh tickets (like on a workstation) a valid one?   If so, where 
should I concentrate my efforts to get this working?

Hi,

please have a look at the krb5_renew_interval option explained in the
sssd-krb5 man page.

To my knowledge, when SSSD renews tickets, it does so forever, even after the 
user has logged out. It’s worth making sure people know about that, since it 
can create an unexpected exposure.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org

[SSSD-users] Re: sssd - ssh and ticket renewal

[Sumit Bose]

On Mon, Nov 04, 2019 at 04:01:20PM +, Jay McCanta wrote:
> I've been working with SSSD for a good while and I could have sworn I knew 
> how to get this working, but
> 
> Login on workstations via GDM and my Kerberos tickets get renewed 
> automatically.  As I type this, I realize that I do lock/unlock my screen at 
> least once a day.  My tickets never seem to expire on my workstation.
> From my workstation, I ssh to a server with sssd enabled authentication 
> (Ubuntu bionic on both ends).  I use a different account on the remote server 
> and am asked for a password.  Ssh is configured to use PAM and has it's own 
> password authentication disabled.  (PasswordAuthentication no;  UsePAM yes; 
> ChallengeResponseAuthentication yes).  Home folders are kerberized NFS 
> and upon initial login, all is well.  However the ticket for this session 
> never renews on its own.  sudo will refresh the ticket.  It's about the only 
> other thing we have sssd enable for besides ssh.   Without any sudo activity, 
> the Kerberos ticket expires and we lose access to home folders.  Current 
> workaround is a user cron job that tries to refresh the key every hour.  I 
> have to sudo on this server several times a day so my tickets were being 
> renewed.  CO-workers don't have sudo access and they are the ones losing 
> their tickets.
> 
> Is my assumption that one should be able to ssh to a server and have that 
> server refresh tickets (like on a workstation) a valid one?   If so, where 
> should I concentrate my efforts to get this working?

Hi,

please have a look at the krb5_renew_interval option explained in the
sssd-krb5 man page.

HTH

bye,
Sumit

> 
> Thanks to all in this group.
> 
> [cid:image001.jpg@01D592E5.F6CEED20]
>  Jay McCanta  |  Principal Systems Administrator
>  D +1 (206) 272-7998  M +1-206-434-1080
> 
> 



> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@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.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org

[SSSD-users] Re: best way to check if a host is in a net group

[Charles Hedrick]

test,c
#include 
#include 
#include 


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@cs.rutgers.edu
  Principal alias: host/ilab1.cs.rutgers@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.917908 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.418212 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  wrote:
> 
> On Thu, Oct 31, 2019 at 02:02:51PM +, 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 

[SSSD-users] sssd - ssh and ticket renewal

[Jay McCanta]

I've been working with SSSD for a good while and I could have sworn I knew how 
to get this working, but

Login on workstations via GDM and my Kerberos tickets get renewed 
automatically.  As I type this, I realize that I do lock/unlock my screen at 
least once a day.  My tickets never seem to expire on my workstation.
>From my workstation, I ssh to a server with sssd enabled authentication 
>(Ubuntu bionic on both ends).  I use a different account on the remote server 
>and am asked for a password.  Ssh is configured to use PAM and has it's own 
>password authentication disabled.  (PasswordAuthentication no;  UsePAM yes; 
>ChallengeResponseAuthentication yes).  Home folders are kerberized NFS and 
>upon initial login, all is well.  However the ticket for this session never 
>renews on its own.  sudo will refresh the ticket.  It's about the only other 
>thing we have sssd enable for besides ssh.   Without any sudo activity, the 
>Kerberos ticket expires and we lose access to home folders.  Current 
>workaround is a user cron job that tries to refresh the key every hour.  I 
>have to sudo on this server several times a day so my tickets were being 
>renewed.  CO-workers don't have sudo access and they are the ones losing their 
>tickets.

Is my assumption that one should be able to ssh to a server and have that 
server refresh tickets (like on a workstation) a valid one?   If so, where 
should I concentrate my efforts to get this working?

Thanks to all in this group.

[cid:image001.jpg@01D592E5.F6CEED20]
 Jay McCanta  |  Principal Systems Administrator
 D +1 (206) 272-7998  M +1-206-434-1080


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org