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.
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:
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.
Repeat the test so you would see the error.
Collect the log file from the client. You would see what server it has queried to get the information.
Check server’s log. Most likely there is no requested information on this LDAP instance due to replication issues.
If your organization uses Google Apps as mail service but you are using Evolution, there is no evident way to view and edit shared group calendars until recent versions. To add group calendar you need:
go to calendar settings on web
Calendar Address: -> ID (somenting like firstname.lastname@example.org)
Evolution -> New Calendar -> Google
User name -> this ID
Auth with usual name-pass or other means you use (Kerberos, OTP) in the window appear.