kinit -R seems to do the trick for me. I'm tempted to suggest just having a LaunchAgent that runs this command with a StartInterval of, say, 7200 seconds (2 hrs); you could get fancier (e.g. testing network connectivity first, adjusting the retry frequency as your TGT gets closer to expiring, etc), but I think you'd mostly be going to a lot or work to avoid a tiny bit of computational expense.
Samba means different things to different people. To some, it is a way to implement LanMan-style networking without tithing to Microsoft, using WinBind to provide pseudo Domain Controller services without actually running a Windows Server. This is perhaps why ‘drookie’ made the comment “Seems like you have AD running but for some reason you don't want to use it. Why using samba then anyway?”. Why? Because I’m using Samba mainly for the basic CIFS support. All that extra WinBind/ADS home-dir and cached DC data cruft is something I didn’t really want. I was looking for Linux to still define authorization & access, not open it up to all domain users. But for the users that are allowed, use Kerberos authentication. (Samba – especially Samba4 – is heading towards full Active Directory emulation of Linux nodes in a Windows AD domain, all the way down to inheritance of SID/GUID, OU membership, etc. Their goal is to have no need to create Linux local accounts because Samba will create them on-the-fly based on AD profiles. Overkill for my needs.)
Since I was looking to Samba primarily for the CIFS functionality, I was hoping that AD could be used only for the authentication part via the Kerberos calls (as I have already implemented for SSH). If I didn’t need domain-join to have Kerberos work at the TTY/SSH level, did I really need it for Samba+Kerberos? Unfortunately, the answer is YES. But despite that, I was still able to accomplish my goal of AD/Kerberos authn without turning the Linux host into a PDC/BDC or deferring all authz control to ADS mode. What I have works, and this is my interpretation of why:
Basic Kerberos works at the PAM/TTY level because the user is typing their password interactively, fed directly into the krb5 library; when running in context of the user doing the request, no domain-join is needed. However, in the case of authenticating CIFS shares, the Windows client has already encrypted the password that the user typed, so by the time Samba gets it, it is the NTLMv2 hash. This is probably why the O’Reilly “Hornbill book” says “the auth PAM module lines are ignored completely” by Samba. In this case, Samba must contact the AD server securely to retrieve credential details to know for sure if the user/password is correct. For this reason, a domain-join is needed. In essence, the domain-joined Samba is acting as a Kerberos proxy to contact AD and verify the client credentials.
I found that even with a required domain-join, there is no need to run a local WinBind daemon or turn the Linux host into a full AD server. Here is what I did in the Samba4 config file:
security = ADS
passdb backend = tdbsam
realm = DOMAIN.COM
password server = *
encrypt passwords = yes
lanman auth = no
ntlm auth = no # NTLMv2
kerberos method = system keytab
username map = /etc/samba/smbusers
guest account = nfsnobody
map to guest = Bad User
obey pam restrictions = yes
It’s probably more significant to point out what I did not do:
- winbind directives are omitted from the smb.conf config file
- the winbind service is not enabled/running (to cache AD data as if it were a DC)
- winbind was not added to /etc/nsswitch.conf (to use the domain as a
valid local-user source)
- winbind and mkhomedir are not added to /etc/pam.d/system-auth (to
allow domain users to login and create accounts on-the-fly)
The bare minimum is that a domain-join is required to enable the Kerberos lookup relative to local-user access:
# net ads join -U Administrator
# net ads keytab create
However, no services are enabled that would turn the Linux host into a card-carrying access-authorizing PDC/BDC or ADS substitute. I am using Samba+Kerberos strictly for local user validation and nothing more.
Best Answer
It's the end of 2018 and I've run into the same question as you. After some digging, I can offer a write-up for posteriority.
tl; dr:
First off, you can't have "indefinitely". Kerberos tickets have a maximum renewable lifetime which is a KDC server setting, and nothing will let you renew one ticket past this time. The only thing you could do is store the users credentials and request a fresh new ticket on their behalf.
That being said, you shouldn't have to. Chances are that you are running the "System Security Services Daemon", or SSSD. If you do, you can use the builtin renewal options
krb5_renew_intervalandkrb5_renewable_lifetimeto renew users tickets automatically:You can look into
man 5 sssd-krb5for details. With these settings SSSD will ask for renewable tickets (maximum lifetime 90 days) whenever you log in* and every 500 seconds go through a list of tickets* and renew the existing tickets that are renewable.After 90 days have passed since the original ticket, the renewal will fail and the ticket is lost. However, if you log in* in the mean time, you will get a fresh ticket from SSSD - even when you enter your password into your machines lock screen.
*) So far, so wonderful. Unfortunately, a few gotchas apply.
At the time when I am writing this, SSSD can only renew tickets that it itself requested. These are all the logins that go through the
pam_sssPAM module, for example (but not limited to):su $USERon your terminalPasswordAuthenticationmethod.Now what is notably missing from this list is:
kinitPubkeyAuthenticationmethod.GSSAPIAuthenticationmethod.GSSAPIDelegateCredentialsoption is on.Now that makes things quite awkward, and for the time being it essentially means that eitheryou force users to enter a password or that you write a ticket renewal daemon yourself. I have not found another way to make this work in the present, please anybody comment if you found a way.
This might become quite a bit easier, however.
SSSD now provides a "kerberos cache manager", a KCM that's called sssd-kcm. Basically, it's a small server that will store tickets there (
KCM:when you runklist) instead of the Kernel keyring (KEYRING:when you runklist) or a file in /tmp (FILE:when you runklist).At some point in the future, SSSD will hopefully be able to renew all tickets (not just the ones it requested itself) when
sssd-kcmimplements ticket renewal. This has not happened yet, and is tracked in issue 1723 on the SSSD bug tracker.If you're running a Red Hat based system (RHEL, CentOS, Fedora), then SSHD also needs to learn to respect the selected cache creation mechanism. This is tracked in issue 1639376 on the Red Hat bugtracker.