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 '[email protected]'
[root@m1 ~]# klist
Ticket cache: KCM:0
Default principal: [email protected]
Valid starting Expires Service principal
05/11/21 14:38:14 05/12/21 00:38:14 krbtgt/[email protected]
renew until 05/12/21 14:38:14
[root@m1 ~]# ldapmodify -Y GSSAPI -h dc.ad.test
SASL/GSSAPI authentication started
SASL username: [email protected]
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
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
