Categories
Linux

SSSD – Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

Errors Seen

The message Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. is seen in your syslog (/var/log/messages or similar).

The message [[sssd[ldap_child[PIDXX]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed is seen in /var/log/sssd/ldap_child.log.

Any domain-based logins fail with Authentication service cannot retrieve authentication info (using PAM).

Why

The krb5.keytab is most likely corrupt. This could be due to no disk space left when writing to it or other IO errors.

As any solutions to fix the keytab will try to actually read and try to fix the incorrect data, they will mostly fail as the file is too damaged.

Solution

There are many ways to recreate the krb5.keytab and they will differ depending on your setup. RESEARCH THIS BEFORE YOU GO AHEAD as you might have to recreate the entire server in the domain, depending on its function.

As we were using the keytab for normal sign-ins and nothing else, the best way for us was to recreate it all over.

Just rejoining the domain did not work as it attempted to write to the already available keytab, so we had to remove the krb5.keytab entirely and then join the domain again.

Test with using <code>id <adusername></code>.

Categories
Linux SUSE

SUSE – SSSD domain joining fails with error “Internal error” and “Details: host/port don’t match”

Errors Seen

Using yast2, when using the User Logon Management or User Logon and attempting to domain join, you will see an error like this:

file

Why

This error has been seen when moving from samba domain join to SSSD as well as changing domains.

It is due to the cache having different information that is not being overwritten when attempting to join with SSSD, most likely the kerberos keytabs, although where exactly it is getting the wrong information from is a guess.

Solution (kinda)

Clear the domain cache. This is done in yast2 in the User Logon Management or User Logon, depending on the version.

file

Sometimes, this does not seem to be enough and you will have to install SSSD separately instead of making yast2 do it once it needs to do it.

sudo zypper install sssd

Having said all this, I have seen the above not work in more than a few situations and coming back a few minutes/hours later and suddenly it works. It seems to be more a yast2 issues than something else, as it is part of the resolver/resolving of the domain.

Troubleshooting have let to nowhere.

Categories
Linux SUSE

SUSE, Fedora – Auditd rules does not seem to work

Errors Seen

None of the custom rules set in /etc/audit/rules.d/ seems to be accepted, despite being shown when running auditctl -l

This issue has been seen on SUSE Linux Enterprise Server (SLES) 15 SP2 and Fedora 22 and onward.

Why

A default rule set in /etc/audit/rules.d/audit.rules disables any rules using SYSCALL, which overrides any other rules set.

## This suppresses syscall auditing for all tasks started
## with this rule in effect.  Remove it if you need syscall
## auditing.
-a task,never

This was added to minimize logging of auditd.

Solution

Edit /etc/audit/rules.d/audit.rules and comment out -a task,never.

The entirety of the file should look like this, if no changes have been made:

## This suppresses syscall auditing for all tasks started
## with this rule in effect.  Remove it if you need syscall
## auditing.
#-a task,never
Categories
Linux

Auditd – WARNING – 32/64 bit syscall mismatch in line, you should specify an arch

Errors Seen

The following is seen in your syslog/messages log file upon start/restart of auditd:

augenrules[13977]: WARNING - 32/64 bit syscall mismatch in line 121, you should specify an arch

Why

According to the manpage for audit.rules

If you get a warning from auditctl saying, "32/64 bit syscall mismatch in line XX, you should specify an arch". This means that you specified a syscall rule on a bi-arch system where the syscall has a different syscall number for the 32 and 64 bit interfaces. This means that on one of those interfaces you are likely auditing the wrong syscall.

Solution

Divide the rule into 2, and adding the arch, for example:

-always,exit -S openat -k access`

becomes

-always,exit -F arch=b32 -S openat -k access
-always,exit -F arch=b64 -S openat -k access

Essentially adding -F arch=b32 and -F arch=b64. Notice that they need to be the very first argument set right after always,exit or similar.