> On ti, 11 touko 2021, Owen Vincent via FreeIPA-users wrote: > > Yes, this is significant info. OK, this might explain *WHY* it happens. > When shared secret is used to create the trust, we have no credentials > to force the encryption types on the TDO and we rely on the defaults in > AD to do so. I suspect your problem here is that your AD defaults do not > set AES types with some group policy definition and thus only RC4-HMAC > is set there as it is a default one. > Ok this makes sense and might explain the user behavior. The AD forest functional level is 2008 R2, which defaults to just RC4, but the domain functional level is 2012 R2, so the default user settings might be different because of that.
> Can you try by adding msDS-SupportedEncryptionTypes: 28 to the TDO > object? > This is what I have been trying to do. Both with the check box in the GUI and via directly editing the attribute. But the check box is grayed out and trying to edit the attribute directly produces the following error: "Operation failed. Error code: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted. 00002077: SvcErr: DSID-0319039A, problem 5003 (WILL_NOT_PERFORM), data 0." So there seems to be something about how AD sees the trust that makes it really not want to allow changes to the encryption type. I’ll report back when I hear from our AD admin how it went trying to change the enctypes with ksetup. > Then re-try the test sequence I gave you in the previous email. > > If that doesn't work, re-establish the trust using AD admin credentials. > This might be tricky as we don’t have AD admin credentials. Do you have any experience with creating one way trusts using credentials of a user in the Incoming Forest Trust Builders AD group? That seems like the most likely way we could get the AD administrators to give us an account that had any chance of creating the trust. > Shared secret trust has a lot of limitations. For example, we cannot use > it in FIPS mode because we cannot activate AD side of the trust with it > (NTLMSSP is not supported in FIPS), we always have to use Kerberos and > Kerberos would not work in FIPS mode for RC4-HMAC. It also doesn't work > for non-FIPS environment by default in RHEL 8.3+/Fedora because > system-wide crypto policy blocks RC4-HMAC. > > > IPA$ doesn't have msDS-SupportedEncryptionTypes. It is mostly set on > service principals, as per MS-KILE. Note that IPA$ is not used for > cross-realm communication, TDO does. IPA$ is only used by SSSD to talk > to AD DC to lookup identities and it doesn't require cross-realm to work > because IPA$ principal is within AD domain. > That makes sense. > > Yes, this is something to find out in Windows documentation. > > > Yep, this means krbtgt/IPA@AD does not have AES encryption type keys. > Which is explainable with shared secret trust and default AD group > policy for the encryption types. > I’ll have to look into if there is a method to define encryption settings for only forest trusts in AD. From what I have seen there are only general settings for Kerberos, which I assume would apply to users and hosts as well. > > Re-creating with admin credentials should work. If you are able to find > out if TDO can be updated as it is, please report back. Sadly, we simply > have no way to update the entry from IPA side without AD admin > credentials until the trust is verified. The goal is to figure this out with as little work on the AD side as possible. Ideally the ksetup method of setting the trusts encryption settings will work and that will be that. If not then we will have to look into options for either defining a set of rules for the trust before it gets created and recreate it with viable settings using a shared secret or getting one of the AD admins to either enter their password or create an account in the Incoming Forest Trust Builders group and see if that works. One last thing, since you say “Sadly, we simply have no way to update the entry from IPA side without AD admin credentials until the trust is verified.” Our trust has been verified from the AD admins, does that give us an option to push encryption setting back to the AD? Does the IPA$ user have write privileges for the TDO? Or something like that? Best, Owen _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
