Controls/gitea-pages
0
2
Fork 0
Code Pull Requests Actions Activity

document AD join failure

Browse Source
This commit is contained in:
buchel_k
2023-02-23 17:03:30 +01:00
parent cc80d744b6
commit 9fc16a8506
2 changed files with 32 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
admin-guide/troubleshooting/login.md Normal file
View File

@@ -0,0 +1,32 @@
# Login and Remote Access
When a user cannot log in on a system, it is usually caused by one of these:
1. The password is wrong.
2. Access hasn't been granted through Hiera (`aaa::admins` and `aaa::users`)
or `/etc/security/ssh.allow.*`. The latter also has to be enabled in Hiera.
3. Log in as root is attempted from a system that is not a bastion host (eg
`wmgt0*.psi.ch` or `*-gw.psi.ch`).
4. In the case of Gnome logins, the problem might be caused by the home
directory being inaccessible (eg because AFS doesn't work properly).
5. [`sssd(8)`](https://linux.die.net/man/8/sssd) may have problems.
Regarding #3 note that on some systems the configured bastion host is
`wmgt*.psi.ch` even though it is not actually possible to log in from there,
because the PSI firewall only allows connections from a certain gateway, eg
`foobar-gw.psi.ch`.
## Known Errors
### pam_sss System Error
```
pam_sss(sshd:account): Access denied for user xxxxxx_y: 4 (System error)
```
Here the AD join might be broken. The machine can be rejoined by deleting/moving away `/etc/krb5.keytab` and then running Puppet (`puppet agent -t`).
## Notes
For normal users there will be a [`pam_access(8)`](https://linux.die.net/man/8/pam_access) error even for
successful logins. The reason is that we use pam_access twice. First for admins
and then - depending on the system's configuration - for normal users. Obviously
the first one will fail unless the user in question is recognized as an admin.

28
admin-guide/troubleshooting/login.rst
View File

@@ -1,28 +0,0 @@
=========================
Login and Remote Access
=========================
When a user cannot log in on a system, it is usually caused by one of these:
1. The password is wrong.
2. Access hasn't been granted through Hiera (``aaa::admins`` and ``aaa::users``)
or ``/etc/security/ssh.allow.*``. The latter also has to be enabled in Hiera.
3. Log in as root is attempted from a system that is not a bastion host (eg
``wmgt0*.psi.ch`` or ``*-gw.psi.ch``).
4. In the case of Gnome logins, the problem might be caused by the home
directory being inaccessible (eg because AFS doesn't work properly).
5. :manpage:`sssd(8)` may have problems.
Regarding #3 note that on some systems the configured bastion host is
``wmgt*.psi.ch`` even though it is not actually possible to log in from there,
because the PSI firewall only allows connections from a certain gateway, eg
``foobar-gw.psi.ch``.
Notes
=====
For normal users there will be a :manpage:`pam_access(8)` error even for
successful logins. The reason is that we use pam_access twice. First for admins
and then - depending on the system's configuration - for normal users. Obviously
the first one will fail unless the user in question is recognized as an admin.