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 >
