And OK, remembered this too ☺ The clocks of all servers in a Kerberos domain must be tightly sync'd and under control of a local master clock. That's because of the timestamps in the Kerberos tickets. Authentication fails without it. And again as with name resolution, that config must be complete before you obtain the Kerberos TGT.
On Tue, Feb 23, 2021, 8:30 AM Nicholas Geovanis <nickgeova...@gmail.com> wrote: > Let me add this if I may Kent, esp for others who might go there. When you > first configure the linux server into an LDAP/AD or LDAP domain, you MUST > complete the "final production" name resolution/resolver/DNS config BEFORE > joining the domain. If you don't but later move it into that domain, it > still won't authenticate right. And that really has to do with Kerberos > setup, esp the TGT and ticketing. Doing the setup in docker or a Xen VM > doesn't change that fact. > > On Mon, Feb 22, 2021, 3:12 PM Nicholas Geovanis <nickgeova...@gmail.com> > wrote: > >> On Mon, Feb 22, 2021, 1:47 PM Kent West <we...@acu.edu> wrote: >> >>> >>> >>> On Mon, Feb 22, 2021 at 1:37 PM Kent West <we...@acu.edu> wrote: >>> >>>> >>>> >>>> On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis < >>>> nickgeova...@gmail.com> wrote: >>>> >>>>> On Sun, Feb 21, 2021, 5:09 PM Kent West <we...@acu.edu> wrote: >>>>> >>>>> Brand new Debian box (tried Buster, then when that didn;' work, >>>>> upgraded tp unstable - meh, it's a test box to get things sorted out >>>>> before >>>>> production use). >>>>> .... >>>>> su'd to root >>>>> >>>>> apt install'd aptitude, realmd, packagekit >>>>> >>>>> (packagekit grabbed the needed dependencies, such as sssd and samba >>>>> (at least parts of them, and maybe part of KRB5 (the keytab thing-y), and >>>>> [mostly] configured them) >>>>> >>>>> Ran "realm join MY.DOMAIN -U my_add-to-domain_user" >>>>> >>>>> getent passwd domain_user successfully returns data on the domain user: >>>>> >>>>> acutech@21260-debianvm:~$ getent passwd glerp@my.domain >>>>> glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@my.domain >>>>> :/bin/bash >>>>> .... >>>>> .... >>>>> >>>>> Here are a few relevant lines from /var/log/auth.log: >>>>> >>>>> Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_unix(sshd:auth): >>>>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >>>>> rhost=127.0.0.1 user=glerp@my.domain >>>>> Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_sss(sshd:auth): >>>>> authentication success; logname= uid=0 euid=0 tty=ssh ruser= >>>>> rhost=127.0.0.1 user=glerp@my.domain >>>>> Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_sss(sshd:account): >>>>> Access denied for user glerp@my.domain: 6 (Permission denied) >>>>> Feb 21 17:04:54 21260-debianvm sshd[5284]: Failed password for >>>>> glerp@my.domain from 127.0.0.1 port 59998 ssh2 >>>>> Feb 21 17:04:54 21260-debianvm sshd[5284]: fatal: Access denied for >>>>> user glerp@my.domain by PAM account configuration [preauth] >>>>> >>>>> >>>>> So I think what this is telling you is that authentication succeeded >>>>> for the "auth" clause in the "sshd" section of the PAM config file >>>>> (pam_sss). But then authentication failed in the "account" clause of the >>>>> sshd section. >>>>> >>>>> So the question is why there? >>>>> >>>>> >>>> ..... >> >>> >>>> I built another virtual machine on another Debian box, following the >>> same steps. That one worked. >>> >>> I compared all the files I could think of (/etc/pam.d/ files, >>> /etc/nsswitch.conf, /etc/ssd/ssd_config, etc), and made them identical. >>> Didn't help. >>> >>> I then rebuilt the offending machine, removed it from the domain, >>> followed the same steps again, and now ... it works. >>> >>> Go figure. >>> >> >> And having been on that merry-go-round myself more than once, Mr West☺ >> ....that usually means something bad happened in the initial Kerberos >> ticket granting process that happens at LDAP/AD initial config. First you >> need a ticket-granting-ticket from the LDAP or AD domain (the TGT). And >> then you need a session ticket for each kerberos session. Those sessions >> are usually much shorter than the lifetime of a single boot. So sometimes >> they need to be re-acquired outside of the boot process. And yes, >> nsswitch.conf is vital. >> >> There are folks on debian-user who understand it better than me. The >> first time I did that was on Solaris 8 however. Built LDAP, nss and AD >> interface code from source. No base config files except for PAM. Took a few >> tries but it worked. It's hard to shake out and you did it. >> West in pieces... ☺ >> >> I would have loved to have found the problem, but more importantly for >>> me, I now know the process works. For now, that's sufficient. >>> >>> >>> >>> -- >>> Kent West <")))>< >>> Westing Peacefully - http://kentwest.blogspot.com >>> >>
