You have create a transit trust between 2 forest and tested and they work. You have followed the instruction in the KB Article SOL45637 but still authentication fails for cross forest users.
root@stewie vastool -u testuser -e auth
Password for testuser@EMEA.example.COM:
ERROR: VAS_ERR_KRB5: Kerberos error
Caused by:
KRB5KRB_AP_ERR_ILL_CR_TKT (-1765328341): Invalid cross-realm ticket
Reason: no transit through realm Example.COM
Please see the addition information below.
This is a Heimdal Kerberos limitation.
1) Edit the /etc/opt/quest/vas/vas.conf file
add a cpaths section for your environment
For example your setting will look similiar to this:
[capaths]
emea.example.com = {
amrs.quest.com = example.com
}
This information is from the Heimdal Kerberos Documentation:
If you want to use cross realm authentication through an intermediate realm, it must be explicitly allowed by either the KDCs or the server receiving the request. This is done in krb5.conf in the [capaths] section.
When the ticket transits through a realm to another realm, the destination realm adds its peer to the "transited-realms" field in the ticket. The field is unordered, since there is no way to know if know if one of the transited-realms changed the order of the list.
The syntax for [capaths] section:
[capaths] CLIENT-REALM = { SERVER-REALM = PERMITTED-CROSS-REALMS ... }
The realm STACKEN.KTH.SE allows clients from SU.SE and DSV.SU.SE to cross it. Since STACKEN.KTH.SE only have direct cross realm with KTH.SE, and DSV.SU.SE only have direct cross realm with SU.SE they need to use both SU.SE and KTH.SE as transit realms.
[capaths] SU.SE = { STACKEN.KTH.SE = KTH.SE } DSV.SU.SE = { STACKEN.KTH.SE = SU.SE KTH.SE }
The order of the PERMITTED-CROSS-REALMS is not important when doing transit cross realm verification.
However the order is important when the [capaths] section is used to figure out the intermediate realm to go to when doing multi-realm transit. When figuring out the next realm, the first realm of the list of PERMITTED-CROSS-REALMS is chosen. This is done in both the client kerberos library and the KDC.
</snip>
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center