On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
On Fri, 05 Dec 2014, Andreas Ladanyi wrote:
I'm also getting errors but they are different to yours. Here is what I
did:
(on master.f21.test, realm F21.TEST):
[root@master ~]# kadmin.local -x ipa-setup-override-restrictions -r
F21.TEST
Authenticating as principal root/ad...@f21.test with password.
kadmin.local: addprinc -requires_preauth krbtgt/IPA5.TEST
WARNING: no policy specified for krbtgt/ipa5.t...@f21.test; defaulting
to no policy
Enter password for principal "krbtgt/ipa5.t...@f21.test": Re-enter
password for principal "krbtgt/ipa5.t...@f21.test": Principal
"krbtgt/ipa5.t...@f21.test" created.
kadmin.local: addprinc -requires_preauth krbtgt/f21.t...@ipa5.test
WARNING: no policy specified for krbtgt/f21.t...@ipa5.test; defaulting
to no policy
Enter password for principal "krbtgt/f21.t...@ipa5.test": Re-enter
password for principal "krbtgt/f21.t...@ipa5.test": Principal
"krbtgt/f21.t...@ipa5.test" created.
kadmin.local: q
added following to the /etc/krb5.conf:
[libdefaults]
dns_lookup_realm = true
[domain_realms]
.ipa5.test = IPA5.TEST
ipa5.test = IPA5.TEST
Why only one domain and one realm if you have two REALMs ?
Because this is what I _added_. The F21.TEST entries were already in
place.
On this position i have another question:
I have 2 REALMs and one DNS domain.
.domainname_X = REALM A
domainname_X = REALM A
.domainname_X = REALM B
domainname_X = REALM B
Could this work clear ?
No. What realm would it select if the domain name is the same? Either
you define explicitly per each host which realm the host belongs to or
you'd have different DNS domains for the realms.
"krbtgt/ipa5.t...@f21.test" created.
kadmin.local: q
Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
did you use them ?
Because this is recommended by MIT documentation. The link between
realms has to be protected well, including preauth and good passwords
for the cross-realm principals.
and similar changes to /etc/krb5.conf.
Then I tried to get a ticket to host/master.f21.t...@f21.test while
being an ad...@ipa5.test:
I tried out this on the IPA box to connect to the non IPA box (foreign
realm).
[root@ipa-05-m ~]# kinit admin
Password for ad...@ipa5.test: [root@ipa-05-m ~]#
KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
[22351] 1417689782.154516: Convert service host (service with host as
instance) on host master.f21.test to principal
[22351] 1417689782.158724: Remote host after forward canonicalization:
master.f21.test
[22351] 1417689782.158814: Remote host after reverse DNS processing:
master.f21.test
[22351] 1417689782.158849: Get host realm for master.f21.test
[22351] 1417689782.158899: Use local host master.f21.test to get host
realm
[22351] 1417689782.158946: Look up master.f21.test in the domain_realm
map
[22351] 1417689782.158999: Look up .f21.test in the domain_realm map
[22351] 1417689782.159023: Temporary realm is F21.TEST
[22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
[22351] 1417689782.159071: Got service principal
host/master.f21.t...@f21.test
[22351] 1417689782.159098: Getting credentials ad...@ipa5.test ->
host/master.f21.t...@f21.test using ccache KEYRING:persistent:0:0
[22351] 1417689782.159237: Retrieving ad...@ipa5.test ->
host/master.f21.t...@f21.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[22351] 1417689782.159297: Retrieving ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[22351] 1417689782.159411: Retrieving ad...@ipa5.test ->
krbtgt/ipa5.t...@ipa5.test from KEYRING:persistent:0:0 with result:
0/Success
[22351] 1417689782.159453: Starting with TGT for client realm:
ad...@ipa5.test -> krbtgt/ipa5.t...@ipa5.test
[22351] 1417689782.159502: Retrieving ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[22351] 1417689782.159530: Requesting TGT krbtgt/f21.t...@ipa5.test
using TGT krbtgt/ipa5.t...@ipa5.test
[22351] 1417689782.159576: Generated subkey for TGS request:
aes256-cts/54E6
[22351] 1417689782.159628: etypes requested in TGS request:
aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
camellia256-cts
[22351] 1417689782.159726: Encoding request body and padata into FAST
request
[22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
[22351] 1417689782.159909: Sending initial UDP request to dgram
192.168.5.109:88
[22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
[22351] 1417689782.161925: Response was from master KDC
[22351] 1417689782.162011: Decoding FAST response
[22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
[22351] 1417689782.162127: TGS reply is for ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test with session key aes256-cts/822B
[22351] 1417689782.162159: TGS request result: 0/Success
[22351] 1417689782.162185: Removing ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0
[22351] 1417689782.162207: Storing ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test in KEYRING:persistent:0:0
[22351] 1417689782.162268: Received TGT for service realm:
krbtgt/f21.t...@ipa5.test
[22351] 1417689782.162296: Requesting tickets for
host/master.f21.t...@f21.test, referrals on
[22351] 1417689782.162322: Generated subkey for TGS request:
aes256-cts/61A2
[22351] 1417689782.162359: etypes requested in TGS request:
aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
camellia256-cts
[22351] 1417689782.162413: Encoding request body and padata into FAST
request
[22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
[22351] 1417689782.162493: Resolving hostname master.f21.test
[22351] 1417689782.163213: Sending initial UDP request to dgram
192.168.5.169:88
[22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
[22351] 1417689782.165516: Response was from master KDC
In my case:
[31580] 1417773156.446922: TGS request result: -1765328324/KDC returned
error string: PROCESS_TGS
There is no Decoding FAST response.
This is a detail of your foreign KDC configuration, what features it
exposes and requires.
[22351] 1417689782.165572: Decoding FAST response
[22351] 1417689782.165643: TGS request result: -1765328372/KDC policy
rejects request
[22351] 1417689782.165680: Requesting tickets for
host/master.f21.t...@f21.test, referrals off
[22351] 1417689782.165714: Generated subkey for TGS request:
aes256-cts/FEA9
[22351] 1417689782.165751: etypes requested in TGS request:
aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
camellia256-cts
[22351] 1417689782.165799: Encoding request body and padata into FAST
request
[22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
[22351] 1417689782.165875: Resolving hostname master.f21.test
[22351] 1417689782.166084: Sending initial UDP request to dgram
192.168.5.169:88
[22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
[22351] 1417689782.167642: Response was from master KDC
In my case at this position:
[31580] 1417773156.449640: TGS request result: -1765328324/KDC returned
error string: PROCESS_TGS
kvno: KDC returned error string: PROCESS_TGS while getting credentials for
I found out that at the non IPA KDC (the foreign KDC) isnt a Port 88
available (closed). The ports 464+749 are available.
On the IPA KDC there are ports 88+464+749
Port 88 is the standard KDC port. One can choose to use another ports
but all machines in the realm then should have the required ports
configured properly. 88 is the port for the normal Kerberos
communication, 464 is the port for kpasswd, 749 is kadmin.
See more on
http://web.mit.edu/kerberos/krb5-latest/doc/admin/appl_servers.html#conf-firewall
There is no Decoding FAST response.
[22351] 1417689782.167669: Decoding FAST response
[22351] 1417689782.167709: TGS request result: -1765328372/KDC policy
rejects request
kvno: KDC policy rejects request while getting credentials for
host/master.f21.t...@f21.test
[root@ipa-05-m ~]#
And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
see:
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
path from 'ad...@ipa5.test' to 'host/master.f21.t...@f21.test' via ''
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
ad...@ipa5.test for host/master.f21.t...@f21.test, KDC policy rejects
request
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
path from 'ad...@ipa5.test' to 'host/master.f21.t...@f21.test' via ''
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
ad...@ipa5.test for host/master.f21.t...@f21.test, KDC policy rejects
request
And this is correct for FreeIPA 3.3 or later because we limit trust to
those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
(objectclass=ipaNTTrustedDomain). For the rest we return
KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
rejects request'.
Is it possible or a good idea to add my trust domain, which isnt a AD
domain, manualy to IPA 3.3 ?
Well, you can hack of course, that's up to you. I haven't checked that
myself and cannot give you definitive answer on this path, though.
We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
capaths but I remember we had some issues with krb5 versions prior to
1.12 where capaths from krb5.conf were blocking work of the DAL driver.
I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
this shouldnt be a problem ?!
1.6 does not support cross-realm communication as support for RFC6806
was added only in 1.7. So I don't think your setup would have any chance
to work at all.
Hm.. on the other hand, 1.6 documentation talks about it:
http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
So may be their changelogs aren't as complete as they should be. :)
With the link above you can also see with disabling preauth on the
cross-realm krbtgt records is recommended.
But I think most of your issues were because of the 88 port not being
available and no other means to traverse firewall were configured. That
is, aside from the fact that IPA will reject cross-realm tickets because
of how we programmed DAL driver as I explained above.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
