If a new machine account is created using either the W2K or W2K3 GUI, the userAccountControl attribute for the particular machine is always 4128. The userAccountControl value without the UF_USE_DES_KEY_ONLY (0x200000) flag would cause KDC to vent RC4-HMAC tickets for this particular machine account. This is problematic for Samba built and run without a RC4-HMAC capable KRB5 client. Based on the code, even the "net ads join" did not override userAccountControl if the machine account already exists. The net command was built without RC4- HMAC, thus it always set the UF_USE_DES_KEY_ONLY (0x200000) flag for new machine account. "net ads join" should by default or by command line option to override userAccountControl value. There are always workarounds for this problem, but getting it fixed will make everyone's job easier.
The following is the patch (against 3.0.11) of what the code should do if the machine account exists. It is only for building Samba with KRB5 client lib that does not have RC4-HMAC support. libads\ldap.c if (!exists) { ads_mod_str(ctx, &mods, "cn", machine_name); ads_mod_str(ctx, &mods, "sAMAccountName", samAccountName); ads_mod_str(ctx, &mods, "userAccountControl", controlstr); ads_mod_strlist(ctx, &mods, "objectClass", objectClass); 1486,1496d1485 < } else { < < #ifndef ENCTYPE_ARCFOUR_HMAC < /* The machine accounts created using Windows GUI do not have < * the UF_USE_DES_KEY_ONLY flag set, this behavior causes failed < * to decrypt error for non-RC4-HAMC supported KRB5 clients. < * Update userAccountControl with UF_USE_DES_KEY_ONLY required < * only if ENCTYPE_ARCFOUR_HMAC is not defined. < */ < ads_mod_str(ctx, &mods, "userAccountControl", controlstr); < #endif 1498d1486 } ads_mod_str(ctx, &mods, "dNSHostName", my_fqdn); ads_mod_str(ctx, &mods, "userPrincipalName", host_upn);
code has been rewritten and fixes problem.