On ti, 11 touko 2021, Owen Vincent via FreeIPA-users wrote:
> 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 wonder where does it try to perform this operation -- on AD side or on
IPA side.
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.
I think it should work. This is basically AD permissions issue. If AD
DCs accept the creds, they'll do the checks and they should be allowing
Incoming Forest Trust Builders group according to the Microsoft's
documentation.
> 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?
No, this does not work. I just tried and IPA$ user object does not have
write privileges to TDO:
[root@m1 ~]# kinit -kt /var/lib/sss/keytabs/ad.test.keytab 'IPA$(a)AD.TEST'
[root@m1 ~]# klist
Ticket cache: KCM:0
Default principal: IPA$(a)AD.TEST
Valid starting Expires Service principal
05/11/21 14:38:14 05/12/21 00:38:14 krbtgt/AD.TEST(a)AD.TEST
renew until 05/12/21 14:38:14
[root@m1 ~]# ldapmodify -Y GSSAPI -h dc.ad.test
SASL/GSSAPI authentication started
SASL username: IPA$(a)AD.TEST
SASL SSF: 256
SASL data security layer installed.
dn: CN=ipa.test,CN=System,DC=ad,DC=test
changetype: modify
replace: msDS-SupportedEncryptionTypes
msDS-SupportedEncryptionTypes: 0
modifying entry "CN=ipa.test,CN=System,DC=ad,DC=test"
ldap_modify: Insufficient access (50)
additional info: 00002098: SecErr: DSID-03150F9D, problem 4003 (INSUFF_ACCESS_RIGHTS),
data 0
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland