Hi,

  On bullseye systems in AD environment (managed with sssd),
I observed problems with krb5.conf snippet generation in sssd.log:
   *  (2022-04-14 22:36:18): [be[domain.fr]] [ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: couldn't write new krb5.conf file: /tmp/adcli-krb5-f3rplr/krb5.conf: Permission denied
---adcli output end---

And, indeed, looking into /tmp, I find lots of
/tmp/adcli-krb5-... directories (one per day), all empty, and
all with 600 perms (not 700!).

So, I patched adcli to first print, and then change the umak.
The umask was 0x7f. Now, I force-clear the USER bits (see
the patch at the end).

The main bug probably comes from sssd (setting a wrong umask).
I'm using sssd 2.6.3-1~bpo11+1 (a local rebuild for bullseye)
I fixed the bug in adcli (easier for me to do so, and there
is no reason for adcli to be invoked with such a bogus umask)

Now, with my patch, sssd logs tell me:
(2022-04-16  0:15:39): [be[domain.fr]] [ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: strange umask 7f, setting it to 3f
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-SQMtbL/krb5.d/adcli-krb5-conf-kcm9gK
---adcli output end---

And /tmp/adcli-krb5-SQMtbL directory is correctly removed.

  Regards,
    Vincent

my patch:
--- a/tools/tools.c
+++ b/tools/tools.c
@@ -314,6 +314,15 @@
 	int errn = 0;
 	FILE *fo;

+	{
+		mode_t u = umask(0);
+        	umask(u);
+		mode_t u2 = u & ~(S_IRUSR|S_IWUSR|S_IXUSR);
+		if (u2 != u) {
+			warnx ("strange umask %x, setting it to %x", u, u2);
+			umask(u2);
+		}
+	}
 	krb5_conf = getenv ("KRB5_CONFIG");
 	if (!krb5_conf || !krb5_conf[0])
 		krb5_conf = KRB5_CONFIG;