#krb5 — Public Fediverse posts

@firstyear In the libkrimes README.md you write: "While RFC8009 does exist, it should be noted that no KDC we have tested with supports it in their latest versions (last tested June 2024)."

I wonder which KDC you have tested, because AES-SHA2 has been added in MIT Kerberos 1.15: The aes128-sha2 and aes256-sha2 encryption types are new in release 1.15.

See https://github.com/krb5/krb5/blob/master/doc/admin/conf_files/kdc_conf.rst#encryption-types

Sadly Windowser Server 2025 still doesn't support it yet.

#kerberos #krb5

Here we go. This is a Samba client and server implementing IAKerb support. The client uses the principal from the local KDC on the Samba server to get a Kerberos ticket using IAKerb. This means, we get a krbtgt and service ticket over the SMB connection. No kerberos setup needed on the client.
#samba #smb #iakerb #krb5 #kerberos #localkdc

Here we go. This is a Samba client and server implementing IAKerb support. The client uses the principal from the local KDC on the Samba server to get a Kerberos ticket using IAKerb. This means, we get a krbtgt and service ticket over the SMB connection. No kerberos setup needed on the client.
#samba #smb #iakerb #krb5 #kerberos #localkdc

Here we go. This is a Samba client and server implementing IAKerb support. The client uses the principal from the local KDC on the Samba server to get a Kerberos ticket using IAKerb. This means, we get a krbtgt and service ticket over the SMB connection. No kerberos setup needed on the client.
#samba #smb #iakerb #krb5 #kerberos #localkdc

Here we go. This is a Samba client and server implementing IAKerb support. The client uses the principal from the local KDC on the Samba server to get a Kerberos ticket using IAKerb. This means, we get a krbtgt and service ticket over the SMB connection. No kerberos setup needed on the client.
#samba #smb #iakerb #krb5 #kerberos #localkdc

Here we go. This is a Samba client and server implementing IAKerb support. The client uses the principal from the local KDC on the Samba server to get a Kerberos ticket using IAKerb. This means, we get a krbtgt and service ticket over the SMB connection. No kerberos setup needed on the client.
#samba #smb #iakerb #krb5 #kerberos #localkdc

@abbra and I hack on local KDC support for Linux since a while now. Last week I started to implement socket activation support in MIT Kerberos. Then I created a localkdc project in order to configure and set up a local KDC easily on Linux. We use systemd socket activation to listen on a unix socket (/run/localkdc/kdc.sock) and start the KDC on demand. See the small clip 🙂

https://gitlab.com/cryptomilk/localkdc
https://copr.fedorainfracloud.org/coprs/asn/localkdc/ #krb5 #kerberos #localkdc

Today @abbra and I successfully did the first kinit in MIT Kerberos over a unix domain socket. #krb5 #localkdc

Автомонтирование SMB-шар с использованием KRB5

В некоторых случаях, может потребоваться автоматически на старте хоста монтировать smb-шары не при помощи файла с логином/паролем, а с помощью krb5. Имеется(предусловие):

https://habr.com/ru/articles/836688/

#krb5 #cifs #smb #share #mount #systemd #ubuntu

I have an initial implementation of IAKerb in Samba working.

https://k5wiki.kerberos.org/wiki/Projects/IAKERB

#samba #krb5 #localkdc

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@TomAoki @peteorrall @hl @xdydx I'm surprised ... I didn't expect this to come up in the "enterprise" realm, "just" using kerberized #NFSv4 instead should be pretty fine there and it's probably more the #soho environment that will profit most from some up-to-date #smb client in #FreeBSD 😎 ... but would certainly be very nice to get that!

Also interesting they finally want to move to #MIT #krb5 in base. I'll probably continue to build it from ports, so I can use #LibreSSL instead of #OpenSSL, but still nice, as I found you're e.g. forced to use base #kerberos with the NFS client.

Hmm ... kerberos, for now, does *not* work.

Unfortunately, #FreeBSD's nfs isn't all too verbose about what's failing.

I get: "permission denied" 😎 (and nothing else in logs either).

At least I have an idea. I use MIT #krb5 from ports together with a #samba domain controller, so I build base with WITHOUT_KERBEROS=yes (I really don't need the heimdal from base). Just read the docs again, this also disables gssapi unless you add WITH_GSSAPI=yes. Which I did now. I'm pretty sure kerberized nfs will need libgssapi. We will see....

Impatiently waiting for my #ZFS backup to complete ...

Then the next step will be to test #jailed #NFS (as introduced in #FreeBSD 13.3), to finally replace my horrible hack of redirecting NFS-related traffic with #pf (and, therefore, punching a hole for LAN machines to access the physical host located in the management segment).

I hope to also move to #nfsv4 at the same time. And once *this* works, enable #krb5 auth and encryption. We will see 😎