search for: krb5cc_

...I may know why pam_winbind is not renewing the ticket before it expires. When I SSH from one system in the domain to another system in the domain, SSH is forwarding the ticket to the system.? When I do a klist on the destination system, I see the ticket.? Now,? I have no choice but to use /tmp/krb5cc_<uid> as a ticket cache (because KEYRING simply doesn't work with pam_winbind).? However, when I ssh, and do a klist, the ticket cache file is not actually FILE:/tmp/krb5cc_<uid>.? Instead, it is FILE:/tmp/krb5cc_1004_<10 random chars>.? I don't know if it's SSH tha...

On 10/1/2020 8:34 AM, Rowland penny via samba wrote: > On 01/10/2020 13:30, Jason Keltz via samba wrote: >> On 10/1/2020 8:28 AM, Rowland penny via samba wrote: >> >>> On 01/10/2020 13:17, Jason Keltz via samba wrote: >>>> So why is it that winbind renews the ticket on the original system, >>>> but on the system that I ssh to, it does not.

...10:31:51 -0000 @@ -67,9 +67,6 @@ #ifndef HEIMDAL krb5_creds creds; krb5_principal server; - char ccname[40]; - int tmpfd; - mode_t old_umask; #endif krb5_error_code problem; krb5_ccache ccache = NULL; @@ -146,28 +143,7 @@ goto out; } - snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid()); - - old_umask = umask(0177); - tmpfd = mkstemp(ccname + strlen("FILE:")); - umask(old_umask); - if (tmpfd == -1) { - logit("mkstemp(): %.100s", strerror(errno)); - problem = errno; - goto out; - } - - if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) { -...

The native authentication methods of openssh are (not counting insecure RhostsRSAAuthentication) 1) public key 2) password For users with home dirs in AFS space, method 1) does not work. Except with (non foolproof) fiddling on the access controls within the home directory. This might lead to security issues when done by inexperienced users. Without some work, only 2) remains. Being forced to send

...og, the following was logged on a successful login: Sep 8 15:48:16 dominique login: pam_krb5: pam_sm_authenticate(login jon): entry: Sep 8 15:48:18 dominique login: pam_krb5: pam_sm_authenticate(login jon): exit: success Unfortunately, no credentials were stored in the usual location (e.g. /tmp/krb5cc_<uid>). I've had the following combinations: login auth sufficient pam_krb5.so try_first_pass debug ccache=SAFE login auth sufficient pam_krb5.so try_first_pass debug ccache=/tmp/krb5cc_%u According to the pam_krb5(8) manual page, "The pam_sm_setcred() fu...

Hello, After upgrading from Ubuntu 16.04 to 18.04 printing via SMB-Kerberos no longer works (printing still works in 18.04 when I print via SMB but I don't want to have the password stored in clear text in /usr/lib/cups/backend/smb). In 16.04 I can just type "lpr file.pdf", but when doing this in 18.04 I get "Password for [myuser] on localhost?" and it expects me to type

...s then ssh using GSSAPI to other hosts as defined in my principals using my ticket, achieving SSO. *I wanted to see if I could make the cache file user-specific, instead of the default location (/tmp/krb5cc-blabla).* I configured sssd.conf with: krb5_ccachedir = %h krb5_ccname_template = FILE:%d/.krb5cc_%U I configured krb5.conf with: [libdefaults] default_ccache_name = FILE:/home/%{username}/.krb5cc_%{uid} My sshd_config has the following: KerberosAuthentication yes KerberosOrLocalPasswd no KerberosTicketCleanup yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes GSSAPIStrictAcceptorCh...

...reasons > "just a shot in the dark", if you use kerberos tickets in /tmp then > stuff changed in 18.04 this also broke our cifs automounter > see here > https://blog.nutmeg.at/2017/04/17/getting-pam-krb5-working-autofs-and-cifs/ > i did > default_ccache_name = FILE:/tmp/krb5cc_%{uid} > in /etc/krb5.conf > to fix our problem Thanks you very much for your answer! I tried to set default_ccache_name in /etc/krb5.conf as you suggest above but "lpr" still asks "Password for [myuser] on localhost?". My CIFS mount works fine (as before) and I have $KR...

...ee if a users ticket gets refreshed after 10 hours. Okay - I guess the failure of kdc: lines in smb.conf is a bug. Let's wait and see what happens with your ticket after 10 hours. Maybe there's a bug there as well. Just for fun, I tried to copy the ticket with random characters to /tmp/krb5cc_<uid>, then unset KRB5CCNAME after the SSH, and I too will see after 10 hours whether winbind magically renews the ticket now that the ticket doesn't have the random chars in the name. I'm not using pam_krb5.? I was under the impression it's not necessary.? I'm just using p...

...s internal kerberos support. But both result in errors. When using PAM authentication (using the same PAM stack we're using for local authentication on the clients that works with pam_krb5.so) I can successfully login on the OpenSSH server but don't get the Kerberos5 ticket written to /tmp/krb5cc_[...]. The following error is written to the logs: -- -bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) -- Also the variable KRB5CCNAME isn't defined. I've investigated about this problem already on the net and tried different setups and approaches but to no avail. I...

...the parameter name spelling to the heimdal parameter name. So in the krb5.conf I used "default_cc_name = KEYRING:persistent:%{uid}" instead of "default_ccache_name = KEYRING:persistent:%{uid}". As expected, after making this change the krb5 default ccache name of "FILE:/tmp/krb5cc_%{uid}" is used since "default_cc_name" is not valid. I ran the smbclient command and guess what happened? Remember, the original error in the debug output with the valid parameter name was this: smb_gss_krb5_import_cred ccache[FILE:/tmp/krb5cc_1000] -the caller may retry after a...

...logging in. > The COMPUTER$ should hold it. > Allow the computer to delegate the cifs service. ( or all ) Thing is, the OP is trying to use a users ticket to mount, but seems to be doing it as root, which isn't going to work, mainly because 'root' will use the root ticket /tmp/krb5cc_0. He needs to use the users ticket, typically /tmp/krb5cc_{user_id} He is also setting a credentials file in his mount command, this should be removed. Also, are libnss-winbind, libpam-winbind and libpam-krb5 installed ? I would also point him to your repo: http://apt.van-belle.nl/ This would...

...ark", if you use kerberos tickets in /tmp then >>> stuff changed in 18.04 this also broke our cifs automounter >>> see here >>> https://blog.nutmeg.at/2017/04/17/getting-pam-krb5-working-autofs-and-cifs/ >>> i did >>> default_ccache_name = FILE:/tmp/krb5cc_%{uid} >>> in /etc/krb5.conf >>> to fix our problem >> >> I tried to set default_ccache_name in /etc/krb5.conf as you suggest above but "lpr" still asks "Password for [myuser] on localhost?". >> My CIFS mount works fine (as before) and I have...

...ntly: its auth method saves the user's >Kerberos creds in a memory ccache and stuffs that into the pam handle as >pam data, and its setcred method actually creates the file ccache (and >destroys the memory ccache). The Solaris one does that as well, the ccache file is created as /tmp/krb5cc_<uid> with permissions 600 and owner <uid> >> It will always create a cred cache file owned by PAM_USER, the only >> way you could get the effect you describe above is if you called >> pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item >> to b...

...it, a few weeks later, I noticed that some users were no longer getting their mail if they hadn't logged in during the past day. Postfix's mailq showed that hundreds of messages were backing up in the queue. I eventually tracked it down to leftover Kerberos credential cache files (/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of expired credential files was preventing Postfix from delivering mail to those users' mail spools. If I delete the credential files manually, Postfix immediately delivers the queued emails. Currently, I have a cron job deleting the fil...

...a shot in the dark", if you use kerberos tickets in /tmp then > stuff changed in 18.04 this also broke our cifs automounter > > see here > > https://blog.nutmeg.at/2017/04/17/getting-pam-krb5-working-autofs-and-cifs/ > > i did > > default_ccache_name = FILE:/tmp/krb5cc_%{uid} > > in /etc/krb5.conf > > to fix our problem > > Best Regards > MfG Robert Schetterer > by the way, simply changing did not work on the first try cause the system did in fact used the old functions, in our case i simply did a puppet reinstall during testing phase,...

...roke times before by varia reasons "just a shot in the dark", if you use kerberos tickets in /tmp then stuff changed in 18.04 this also broke our cifs automounter see here https://blog.nutmeg.at/2017/04/17/getting-pam-krb5-working-autofs-and-cifs/ i did default_ccache_name = FILE:/tmp/krb5cc_%{uid} in /etc/krb5.conf to fix our problem Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsicht...

...> there's a bug there as well. It will be in the middle of the night here, so I will report back in the morning, but if it is a bug (not refreshing, that is), then it is an RHEL one, it works on Debian. > > Just for fun, I tried to copy the ticket with random characters to > /tmp/krb5cc_<uid>, then unset KRB5CCNAME after the SSH, and I too will > see after 10 hours whether winbind magically renews the ticket now > that the ticket doesn't have the random chars in the name. > > I'm not using pam_krb5.? I was under the impression it's not > necessar...

...seem to fix the problem. The first is a simple hack of replacing line 287 with 287 authctxt->krb5_ticket_file = NULL. The second is to replace lines 244 and 245 with 244 { 245 char ccname[35]; 246 247 snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d", authctxt->pw->pw_uid); 248 problem = krb5_cc_resolve(authctxt->krb5_ctx, ccname, 249 &authctxt->krb5_fwd_ccache); 250 } (The security implications of the latter make me nervous. I hope Kerberos is handling writing to /tmp carefully and there...

During my test phase I used to manage POSIX attributes in my AD using ldap-tools with -Y GSSAPI after kinit Administrator. Now this became impossible unless I logged in as Administrator, since the principal is tied to the user account - be it only for NFS4. ;) Administrator so far is not even a POSIX user. My first idea was to join my POSIX user to some group, which is allowed to modify user