Google Accounts engine problem and Gnome 3

I have login.keychain corrupted in my Gnome 3 enabled workplace due to the recent Google Accounts engine problem. For some reason it has become completely unusable, Gnome Keychain was unable to unlock it, Google Chrome stopped loading sites, goa-daemon died (as usual) and Evolution has stopped getting mail.

Goog Friday morning frustration.

OOM-killer fun

Recently I had installed RHEL 7 FreeIPA test lab on my workplace. I have made virtual host with default 1GB RAM, installed the system, enrolled it into the IPA domain OK, then tried ipa-replica-install. Turns out that 1GB is not enough and OOM-killer tries to solve the problem by killing processes that ipa-replica-install had spawned. Surprisingly turns out that for some reason the script is not detecting errors caused and you have strangely configured replica as the result.

AD + SSSD

If you have host in the AD with the SSSD then your root user can be any user from the domain. So

%groupname ALL=(ALL) NOPASSWD:ALL

would actually give permissions to all users from the “groupname” to become any AD user they want, and if they’re SSH’ng the localhost then, they would have Kerberos ticket as well. It is not actually that evident, but Active Directory is an identity provider, so if you are superuser on the host — you can be AD user on the host.

Debugging IDM

One of the most frequent cases I have is that “sometimes” and “somewhere” user is not getting authenticated. Trying to SSH to the host works for some users not always, “id username” returns errors sometimes — it’s all the same problem in the environment with LDAP replication. It does not actually matter what kind of the LDAP server or domain controller is being used, always check:

    1. Enable debug log on the client. If the client is SSSD, add “debug_level = 9” to the /etc/sssd/sssd.conf and then restart it. Invalidate its cache if possible.
    2. Repeat the test so you would see the error.
    3. Collect the log file from the client. You would see what server it has queried to get the information.
    4. Check server’s log. Most likely there is no requested information on this LDAP instance due to replication issues.

This would help to identify and fix the problem.