Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #231921 > unrolled thread

AD user can't ssh in

Started byKent West <westk@acu.edu>
First post2021-02-22 00:10 +0100
Last post2021-02-23 15:40 +0100
Articles 9 — 2 participants

Back to article view | Back to linux.debian.user

Contents

  AD user can't ssh in Kent West <westk@acu.edu> - 2021-02-22 00:10 +0100
    Re: AD user can't ssh in Kent West <westk@acu.edu> - 2021-02-22 03:50 +0100
      Re: AD user can't ssh in Kent West <westk@acu.edu> - 2021-02-22 03:50 +0100
    Re: AD user can't ssh in Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-02-22 15:00 +0100
      Re: AD user can't ssh in Kent West <westk@acu.edu> - 2021-02-22 20:40 +0100
        Re: AD user can't ssh in Kent West <westk@acu.edu> - 2021-02-22 20:50 +0100
          Re: AD user can't ssh in Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-02-22 22:20 +0100
            Re: AD user can't ssh in Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-02-23 15:40 +0100
            Re: AD user can't ssh in Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-02-23 15:40 +0100

#231921 — AD user can't ssh in

FromKent West <westk@acu.edu>
Date2021-02-22 00:10 +0100
SubjectAD user can't ssh in
Message-ID<BL61s-54j-3@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

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 glerp@my.domain
glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
glerp@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=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]

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

[toc] | [next] | [standalone]

#231922

FromKent West <westk@acu.edu>
Date2021-02-22 03:50 +0100
Message-ID<BL9sl-6V1-5@gated-at.bofh.it>
In reply to#231921

[Multipart message — attachments visible in raw view] — view raw

On Sun, Feb 21, 2021 at 6:10 PM Tibz Loufok <thiboyz@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
>
> Le lun. 22 févr. 2021 à 00:09, Kent West <westk@acu.edu> a écrit :
>
>> 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 glerp@my.domain
>> glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
>> glerp@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=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]
>>
>> 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                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[toc] | [prev] | [next] | [standalone]

#231923

FromKent West <westk@acu.edu>
Date2021-02-22 03:50 +0100
Message-ID<BL9sl-6V1-1@gated-at.bofh.it>
In reply to#231922

[Multipart message — attachments visible in raw view] — view raw

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

>
>
> On Sun, Feb 21, 2021 at 6:10 PM Tibz Loufok <thiboyz@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.

-- 
Kent




> Regards
>>
>> Le lun. 22 févr. 2021 à 00:09, Kent West <westk@acu.edu> a écrit :
>>
>>> 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 glerp@my.domain
>>> glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
>>> glerp@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=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]
>>>
>>> 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                    <")))><
> Westing Peacefully - http://kentwest.blogspot.com
>


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

[toc] | [prev] | [next] | [standalone]

#231939

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2021-02-22 15:00 +0100
Message-ID<BLjUJ-4Qa-1@gated-at.bofh.it>
In reply to#231921

[Multipart message — attachments visible in raw view] — view raw

On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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 glerp@my.domain
glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
glerp@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=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?

[toc] | [prev] | [next] | [standalone]

#231948

FromKent West <westk@acu.edu>
Date2021-02-22 20:40 +0100
Message-ID<BLpdM-88u-3@gated-at.bofh.it>
In reply to#231939

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis <nickgeovanis@gmail.com>
wrote:

> On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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 glerp@my.domain
> glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
> glerp@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=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?
>
>
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                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[toc] | [prev] | [next] | [standalone]

#231949

FromKent West <westk@acu.edu>
Date2021-02-22 20:50 +0100
Message-ID<BLpnr-8bM-1@gated-at.bofh.it>
In reply to#231948

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 22, 2021 at 1:37 PM Kent West <westk@acu.edu> wrote:

>
>
> On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis <nickgeovanis@gmail.com>
> wrote:
>
>> On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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 glerp@my.domain
>> glerp@my.domain:*:495633057:495600513:glerp:/home/glerp@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 glerp@my.domain 21260-debianvm
>> glerp@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=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?
>>
>>
> 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.
>
>
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.



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

[toc] | [prev] | [next] | [standalone]

#231955

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2021-02-22 22:20 +0100
Message-ID<BLqMy-KY-5@gated-at.bofh.it>
In reply to#231949

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 22, 2021, 1:47 PM Kent West <westk@acu.edu> wrote:

>
>
> On Mon, Feb 22, 2021 at 1:37 PM Kent West <westk@acu.edu> wrote:
>
>>
>>
>> On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis <nickgeovanis@gmail.com>
>> wrote:
>>
>>> On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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
>

[toc] | [prev] | [next] | [standalone]

#231979

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2021-02-23 15:40 +0100
Message-ID<BLH0Z-28p-1@gated-at.bofh.it>
In reply to#231955

[Multipart message — attachments visible in raw view] — view raw

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 <nickgeovanis@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 <nickgeovanis@gmail.com>
> wrote:
>
>> On Mon, Feb 22, 2021, 1:47 PM Kent West <westk@acu.edu> wrote:
>>
>>>
>>>
>>> On Mon, Feb 22, 2021 at 1:37 PM Kent West <westk@acu.edu> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis <
>>>> nickgeovanis@gmail.com> wrote:
>>>>
>>>>> On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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
>>>
>>

[toc] | [prev] | [next] | [standalone]

#231980

FromNicholas Geovanis <nickgeovanis@gmail.com>
Date2021-02-23 15:40 +0100
Message-ID<BLH0Z-28p-3@gated-at.bofh.it>
In reply to#231955

[Multipart message — attachments visible in raw view] — view raw

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 <nickgeovanis@gmail.com>
wrote:

> On Mon, Feb 22, 2021, 1:47 PM Kent West <westk@acu.edu> wrote:
>
>>
>>
>> On Mon, Feb 22, 2021 at 1:37 PM Kent West <westk@acu.edu> wrote:
>>
>>>
>>>
>>> On Mon, Feb 22, 2021 at 7:52 AM Nicholas Geovanis <
>>> nickgeovanis@gmail.com> wrote:
>>>
>>>> On Sun, Feb 21, 2021, 5:09 PM Kent West <westk@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
>>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web