AD user can't ssh in

[Kent West]

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).

Minimal setup (unchecked everything in TaskSel step during install; later used TaskSel to add X11/Mate).

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 gl...@my.domain
gl...@my.domain:*:495633057:495600513:glerp:/home/gl...@my.domain:/bin/bash

I can su to a domain user's account (from root, or from a local user, using the domain user's password). I can also login as a domain user at the console. The domain user does not have a home directory, so I ran "pam-auth-config") and selected the option to auto-create a home dir.

But the domain user can't log in via ssh (a local user can ssh in).

techman@21260-debianvm:~$ ssh -l gl...@my.domain 21260-debianvm
gl...@my.domain@21260-debianvm's password:
Connection closed by 127.0.1.1 port 22

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=gl...@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=gl...@my.domain
Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_sss(sshd:account): Access denied for user gl...@my.domain: 6 (Permission denied)
Feb 21 17:04:54 21260-debianvm sshd[5284]: Failed password for gl...@my.domain from 127.0.0.1 port 59998 ssh2

Feb 21 17:04:54 21260-debianvm sshd[5284]: fatal: Access denied for user gl...@my.domain by PAM account configuration [preauth]

I've pretty much exhausted my troubleshooting skills, and don't know where to go from here. Any help would be appreciated. Thanks!

--

Kent West                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[Kent West]

On Sun, Feb 21, 2021 at 6:10 PM Tibz Loufok <thi...@gmail.com> wrote:

Hi,

I suppose realmd configured sssd.

Yes.

You may need to authorize your users to login. (By using AD gpo or managing it locally).

The parameter is access_provider.

But you can also use realm command to allow locally some AD group.

Also sssd has some logs. You can edit sssd.conf to modify the log level.

Red hat has a good documentation on this subject and it was really helpfull for me as I had to integrate centos and Debian (from 8 to 10). (I configured access locally not by GPO)

I may give you more precise information when I will be at work.

I appreciate the response, and look forward to more precise info, should you be able to provide it.

I've dug through quite a bit of Redhat documentation, but most of it is still beyond me, especially since the specifics don't match Debian setups

Also, about every other hit is behind a paywall, though. For example, just now I searched for "access_provider", and the first hit I tried was a Redhat link, and ran into a paywall. Arg.

Again, thanks for the response!

--

Kent

Regards

[Kent West]

On Sun, Feb 21, 2021 at 8:42 PM Kent West <we...@acu.edu> wrote:

On Sun, Feb 21, 2021 at 6:10 PM Tibz Loufok <thi...@gmail.com> wrote:

Hi,

I suppose realmd configured sssd.

Yes.

You may need to authorize your users to login. (By using AD gpo or managing it locally).

The parameter is access_provider.

But you can also use realm command to allow locally some AD group.

Also sssd has some logs. You can edit sssd.conf to modify the log level.

Red hat has a good documentation on this subject and it was really helpfull for me as I had to integrate centos and Debian (from 8 to 10). (I configured access locally not by GPO)

I may give you more precise information when I will be at work.

I appreciate the response, and look forward to more precise info, should you be able to provide it.

I've dug through quite a bit of Redhat documentation, but most of it is still beyond me, especially since the specifics don't match Debian setups

Also, about every other hit is behind a paywall, though. For example, just now I searched for "access_provider", and the first hit I tried was a Redhat link, and ran into a paywall. Arg.

Again, thanks for the response!

 

Digging a little deeper on "access_provider", it seems that's more related to general authentication into a system, rather than specifically to ssh working for a user. But, since I'm woefully green in this entire realm, I may be wrong.

[Nicholas Geovanis]

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).

Minimal setup (unchecked everything in TaskSel step during install; later used TaskSel to add X11/Mate).

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 gl...@my.domain
gl...@my.domain:*:495633057:495600513:glerp:/home/gl...@my.domain:/bin/bash

....

But the domain user can't log in via ssh (a local user can ssh in).

techman@21260-debianvm:~$ ssh -l gl...@my.domain 21260-debianvm
gl...@my.domain@21260-debianvm's password:
Connection closed by 127.0.1.1 port 22

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=gl...@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=gl...@my.domain
Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_sss(sshd:account): Access denied for user gl...@my.domain: 6 (Permission denied)
Feb 21 17:04:54 21260-debianvm sshd[5284]: Failed password for gl...@my.domain from 127.0.0.1 port 59998 ssh2

Feb 21 17:04:54 21260-debianvm sshd[5284]: fatal: Access denied for user gl...@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?

[Kent West]

As I'm trying to parse this log snippet, I take the line mentioning "pam_unix" to mean that "glerp" is not found in the normal *nix authentication files method (ie, "glerp" is not found in "/etc/passwd").

But the next line indicates that SSS does find "glerp" in its authentication method (ie, authentication via the domain).

So "glerp" was not authenticated as a local user, but he was authenticated as a domain user.

Then the next line says that although "glerp" has been authenticated as a domain user, "glerp" does not have authorization to ssh in, and then the next line says it's because the password is failing.

But that doesn't make sense to me.

[Kent West]

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.

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.

 

[Nicholas Geovanis]

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 <nickge...@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 gl...@my.domain
gl...@my.domain:*:495633057:495600513:glerp:/home/gl...@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=gl...@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=gl...@my.domain
Feb 21 17:04:54 21260-debianvm sshd[5284]: pam_sss(sshd:account): Access denied for user gl...@my.domain: 6 (Permission denied)
Feb 21 17:04:54 21260-debianvm sshd[5284]: Failed password for gl...@my.domain from 127.0.0.1 port 59998 ssh2

Feb 21 17:04:54 21260-debianvm sshd[5284]: fatal: Access denied for user gl...@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... ☺

[Nicholas Geovanis]

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.

[Nicholas Geovanis]

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.