[Samba] nfs4 mounted homedir and kerberos tickets

L.P.H. van Belle belle at bazuin.nl
Wed Sep 9 13:33:33 UTC 2015


Wel.. now im pulling my hair out again.. 
or i did find the problem in putty! 

Without changing anything on the server, but in putty. 

This was already set: 
Connection/SSH/Auth/GSSAPI the boxes "Allow GSSAPI authentication" and "Allow GSSAPI credentials delegation"

I tried the following. 
Connection : Change the protocol from auto to ipv4 
Connection/SSH/Auth/GSSAPI , changed the order of GSSAPI libs, move the MS SSPI to the top. 


Saved, rebooted the print server, and tried again and.. it works now.. 
So i tested a few times again, rebooted the member and print server, typed kdestroy, and keeps working.. while before the error-ed 

I changed the putty settings back to the default, rebooted it all , kdestroy etc, and again it keeps working. 
I dont know why exacly, but not i cant get it to fail again now. 

So for now it all works ok. 

I'll keep you guys posted on this, i'll test again in a few days. 

For so far.. thank you Marcel Rowland, for helping out. 

If i dont get errors anymore in a week, then this must be a putty problem.
Or the change auto=>ipv4 or the switch in GSSAPI libs which fixed it. 

I keep you posted. 

Greetz, 

Louis



> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens L.P.H. van Belle
> Verzonden: woensdag 9 september 2015 14:57
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] nfs4 mounted homedir and kerberos tickets
> 
> Hai marcel,
> 
> I commented in you mail.
> Pff, im learning a lot today..  hard stuff..
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Ritter, Marcel (RRZE) [mailto:marcel.ritter at fau.de]
> > Verzonden: woensdag 9 september 2015 14:38
> > Aan: 'L.P.H. van Belle'; samba at lists.samba.org
> > Onderwerp: AW: [Samba] nfs4 mounted homedir and kerberos tickets
> >
> > Hi Louis,
> >
> > sorry but I'm still having some trouble to unterstand your environment:
> >
> > According to your previous mails here's what I put together:
> >
> > The "member server" has local (not NFS mounted) home directories
> > that are exported to the printserver using sec=krb5, right?
> [L.P.H. van Belle]  Yes, correct
> 
> >
> > The print server is one NFS client mounting this directory, right?
> [L.P.H. van Belle] Yes, correct
> 
> >
> > All further comments are based on these assumptions:
> >
> >
> > > When connection from my windows 7 pc to the print server, i dont get a
> > password prompt, and i automatictly logged in but i get :
> > > Could not chdir to home directory /home/users/someuser: Permission
> > denied And cd /home/users
> > > -bash: cd: /home/users: Permission denied
> >
> > Looks like you can successfully login, but you do not have a valid
> > kerberos ticket to access the NFS home directory.
> [L.P.H. van Belle] yes, thats totaly my problem
> 
> >
> > Check output of "klist" - maybe windows ssh client (putty?) does not
> > forward ticket, and only uses it to authenticate?
> [L.P.H. van Belle] Ok, how can i check this?
> 
> >
> > > When i do the same on the server where the homedir exists,on the
> member
> > server, I can login, without typing password, and the no errors and i am
> > in my user homedir.
> >
> > For accessing a local filesystem you do not require a kerberos ticket,
> > so that's why it works here.
> [L.P.H. van Belle] ok im understanding this.
> 
> >
> > > >    3. cached krb5 credentials on server side
> > > Dont know, how can i see that, like ?
> > > ( login in with someuser on the print server ) klist
> > > klist: Credentials cache file '/tmp/krb5cc_10002' not found
> >
> > Looks like you don't have a kerberos ticket after login at all,
> > this may be caused by a passwordless login (without forwarding
> > ticket) or simply a broken pam_krb5/pam_winbind config.
> [L.P.H. van Belle] ok, a possibilty of a faulty pam config, im using
> pam-auth-update to configure it.
> 
> This is the pam config:
> cat samba
> @include common-auth
> @include common-account
> @include common-session
> 
> Common-auth:
> auth    [success=3 default=ignore]      pam_krb5.so minimum_uid=1000
> auth    [success=2 default=ignore]      pam_unix.so nullok_secure
> try_first_pass
> auth    [success=1 default=ignore]      pam_winbind.so krb5_auth
> krb5_ccache_type=FILE cached_login try_first_pass
> # here's the fallback if no module succeeds
> auth    requisite                       pam_deny.so
> # prime the stack with a positive return value if there isn't one already;
> # this avoids us returning an error just because nothing sets a success
> code
> # since the modules above will each just jump around
> auth    required                        pam_permit.so
> # and here are more per-package modules (the "Additional" block)
> auth    optional                        pam_cap.so
> 
> Common-account
> account [success=2 new_authtok_reqd=done default=ignore]
> pam_unix.so
> account [success=1 new_authtok_reqd=done default=ignore]
> pam_winbind.so
> # here's the fallback if no module succeeds
> account requisite                       pam_deny.so
> # prime the stack with a positive return value if there isn't one already;
> # this avoids us returning an error just because nothing sets a success
> code
> # since the modules above will each just jump around
> account required                        pam_permit.so
> # and here are more per-package modules (the "Additional" block)
> account required                        pam_krb5.so minimum_uid=1000
> 
> Common-password
> password        [success=3 default=ignore]      pam_krb5.so
> minimum_uid=1000
> password        [success=2 default=ignore]      pam_unix.so obscure
> use_authtok try_first_pass sha512
> password        [success=1 default=ignore]      pam_winbind.so use_authtok
> try_first_pass
> # here's the fallback if no module succeeds
> password        requisite                       pam_deny.so
> # prime the stack with a positive return value if there isn't one already;
> # this avoids us returning an error just because nothing sets a success
> code
> # since the modules above will each just jump around
> password        required                        pam_permit.so
> 
> >
> > You don't need to bother about the kernel, if you don't even have
> > a ticket in your cache (as "klist" tells you).
> >
> > > now the magic.. im logged in the member server, in my home dir.
> > > Here I type :
> > > ssh printserver
> > > i must enter my password and im in my homedir.
> > > There where i before (from the windows 7 pc) got :
> > > Could not chdir to home directory /home/users/someuser: Permission
> > denied
> >
> > It's not magic: by entering your password the login host can request a
> > valid kerberos ticket, that is used to access the NFS home.
> > (Once again: "klist" is your friend if you're trying to figure out why
> > somehting works and something else doesn't)
> [L.P.H. van Belle] after a login or through ssh or sudo (so a password
> typed login)
> klist
> Ticket cache: FILE:/tmp/krb5cc_10002_5UGp3pJp88
> Default principal: someuser at INTERNAL.DOMAIN.TLD
> 
> Valid starting       Expires              Service principal
> 09/09/2015 14:45:22  09/10/2015 00:45:22  krbtgt/INTERNAL.DOMAIN.TLD@
> INTERNAL.DOMAIN.TLD
>         renew until 09/10/2015 14:45:22
> 
> 
> >
> > > Now i logout of all servers, klik on putty to login on my print server
> > again and now no errors, all fine, and im sure this is not a keyed.
> >
> > By logging in the last time (with password) a credential cache is
> > created for your user. If not erased on logout it will be valid for
> > a few hours and will be used to access the NFS home.
> > (And even if the cache was removed, it's copy within the kernel
> > might still be valid and used to access the NFS directory)
> >
> > > Now i reboot the print server. Login again from the windows 7 pc.
> > > Again : Could not chdir to home directory /home/users/someuser:
> > Permission denied
> >
> > Because usually during reboot /tmp get's cleaned. And that's
> > the localtion of the credential cache mentioned above
> > ("/tmp/krb5cc_10002")
> >
> > > Other trick to get access to my home dir..
> > > sudo su -
> > > [sudo] password for someuser:
> > >
> > > Now i exit (the sudo)
> > > Type cd ~
> > > And im allowed in my home dir.
> >
> > Depending on your pam config it's quite possible, that "su" uses your
> > password to create a new credential cache for "someuser". Just
> > check the output of "klist" (run as user "someuser") before and after
> > the sudo command ...
> >
> > > Greetz,
> > >
> > > Louis
> >
> > Bye,
> >    Marcel
> [L.P.H. van Belle]
> As extra,
> These are the pam modules of the member server
> ii  libpam-cap:amd64               1:2.24-8                    amd64
> POSIX 1003.1e capabilities (PAM module)
> ii  libpam-krb5:amd64              4.6-3+b1                    amd64
> PAM module for MIT Kerberos
> ii  libpam-modules:amd64           1.1.8-3.1                   amd64
> Pluggable Authentication Modules for PAM
> ii  libpam-modules-bin             1.1.8-3.1                   amd64
> Pluggable Authentication Modules for PAM - helper binaries
> ii  libpam-runtime                 1.1.8-3.1                   all
> Runtime support for the PAM library
> ii  libpam-systemd:amd64           215-17+deb8u2               amd64
> system and service manager - PAM module
> ii  libpam-winbind:amd64           2:4.1.17+dfsg-2             amd64
> Windows domain authentication integration plugin
> ii  libpam0g:amd64                 1.1.8-3.1                   amd64
> Pluggable Authentication Modules library
> 
> and these of the print server.
> ii  libpam-cap:amd64               1:2.24-8                    amd64
> POSIX 1003.1e capabilities (PAM module)
> ii  libpam-krb5:amd64              4.6-3+b1                    amd64
> PAM module for MIT Kerberos
> ii  libpam-modules:amd64           1.1.8-3.1                   amd64
> Pluggable Authentication Modules for PAM
> ii  libpam-modules-bin             1.1.8-3.1                   amd64
> Pluggable Authentication Modules for PAM - helper binaries
> ii  libpam-runtime                 1.1.8-3.1                   all
> Runtime support for the PAM library
> ii  libpam-systemd:amd64           215-17+deb8u2               amd64
> system and service manager - PAM module
> ii  libpam-winbind:amd64           2:4.1.17+dfsg-2             amd64
> Windows domain authentication integration plugin
> ii  libpam0g:amd64                 1.1.8-3.1                   amd64
> Pluggable Authentication Modules library
> 
> 
> You see a missing libpam-winbind, thats correct, sernet-samba-winbindd
> does not provide the modules, but i created that one myself.
> Which is just a copy of the by debian provided libpam-winbind, but i named
> it sernet-samba.
> 
> cat /usr/share/pam-configs/sernet-winbind
> Name: Sernet Winbind NT/Active Directory authentication
> Default: yes
> Priority: 192
> Auth-Type: Primary
> Conflicts: winbind
> Auth:
>         [success=end default=ignore]    pam_winbind.so krb5_auth
> krb5_ccache_type=FILE cached_login try_first_pass
> Auth-Initial:
>         [success=end default=ignore]    pam_winbind.so krb5_auth
> krb5_ccache_type=FILE cached_login
> Account-Type: Primary
> Account:
>         [success=end new_authtok_reqd=done default=ignore]
> pam_winbind.so
> Password-Type: Primary
> Password:
>         [success=end default=ignore]    pam_winbind.so use_authtok
> try_first_pass
> Password-Initial:
>         [success=end default=ignore]    pam_winbind.so
> Session-Type: Additional
> Session:
>         optional                        pam_winbind.so
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba





More information about the samba mailing list