On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
On Fri, 05 Dec 2014, Petr Spacek wrote:
On 5.12.2014 15:21, Andreas Ladanyi wrote:
Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
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.
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.
At this time i havent an idea off the steps in detail how to do that.
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 ?!
Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
1.9.2 and not 1.6
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.
I will look particular for that.
There is no firewall between the two KDCs.
That
is, aside from the fact that IPA will reject cross-realm tickets because
of how we programmed DAL driver as I explained above.
I dont know in detail what DAL is doing.
OK, it sounds like with IPA my setup wont be very easy :-)
I guess that Alexander or Simo could point you to the line in the source code
you have to change (or send you one-line patch?) but you will have to
recompile the driver from source.
Do you want to try this way?
Attached please find a patch that solves the issue of cross-realm trust
for me:
[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
[16101] 1417810641.441614: Convert service host (service with host as instance)
on host master.f21.test to principal
[16101] 1417810641.449424: Remote host after forward canonicalization:
master.f21.test
[16101] 1417810641.449501: Remote host after reverse DNS processing:
master.f21.test
[16101] 1417810641.449549: Get host realm for master.f21.test
[16101] 1417810641.449593: Use local host master.f21.test to get host realm
[16101] 1417810641.449630: Look up master.f21.test in the domain_realm map
[16101] 1417810641.449655: Look up .f21.test in the domain_realm map
[16101] 1417810641.449677: Temporary realm is F21.TEST
[16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test
[16101] 1417810641.449724: Got service principal host/master.f21.t...@f21.test
[16101] 1417810641.449750: Getting credentials ad...@ipa5.test ->
host/master.f21.t...@f21.test using ccache KEYRING:persistent:0:0
[16101] 1417810641.449888: Retrieving ad...@ipa5.test ->
host/master.f21.t...@f21.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[16101] 1417810641.449946: Retrieving ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[16101] 1417810641.450065: Retrieving ad...@ipa5.test ->
krbtgt/ipa5.t...@ipa5.test from KEYRING:persistent:0:0 with result: 0/Success
[16101] 1417810641.450095: Starting with TGT for client realm: ad...@ipa5.test
-> krbtgt/ipa5.t...@ipa5.test
[16101] 1417810641.450144: Retrieving ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result:
-1765328243/Matching credential not found
[16101] 1417810641.450171: Requesting TGT krbtgt/f21.t...@ipa5.test using TGT
krbtgt/ipa5.t...@ipa5.test
[16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06
[16101] 1417810641.450267: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[16101] 1417810641.450364: Encoding request body and padata into FAST request
[16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST
[16101] 1417810641.450559: Sending initial UDP request to dgram 192.168.5.109:88
[16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88
[16101] 1417810641.452241: Response was from master KDC
[16101] 1417810641.452273: Decoding FAST response
[16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3
[16101] 1417810641.452420: TGS reply is for ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test with session key aes256-cts/2C28
[16101] 1417810641.452453: TGS request result: 0/Success
[16101] 1417810641.452479: Removing ad...@ipa5.test ->
krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0
[16101] 1417810641.452509: Storing ad...@ipa5.test -> krbtgt/f21.t...@ipa5.test
in KEYRING:persistent:0:0
[16101] 1417810641.452572: Received TGT for service realm:
krbtgt/f21.t...@ipa5.test
[16101] 1417810641.452600: Requesting tickets for
host/master.f21.t...@f21.test, referrals on
[16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E
[16101] 1417810641.452662: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[16101] 1417810641.452707: Encoding request body and padata into FAST request
[16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST
[16101] 1417810641.452805: Resolving hostname master.f21.test
[16101] 1417810641.453031: Sending initial UDP request to dgram 192.168.5.169:88
[16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88
[16101] 1417810641.456285: Response was from master KDC
[16101] 1417810641.456318: Decoding FAST response
[16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4
[16101] 1417810641.456422: TGS reply is for ad...@ipa5.test ->
host/master.f21.t...@f21.test with session key aes256-cts/5D01
[16101] 1417810641.456456: TGS request result: 0/Success
[16101] 1417810641.456479: Received creds for desired service
host/master.f21.t...@f21.test
[16101] 1417810641.456522: Removing ad...@ipa5.test ->
host/master.f21.t...@f21.test from KEYRING:persistent:0:0
[16101] 1417810641.456564: Storing ad...@ipa5.test ->
host/master.f21.t...@f21.test in KEYRING:persistent:0:0
host/master.f21.t...@f21.test: kvno = 2
[root@ipa-05-m ~]# klist -edf
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@ipa5.test
Valid starting Expires Service principal
05.12.2014 22:17:10 06.12.2014 22:17:10 host/master.f21.t...@f21.test
Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96 05.12.2014 22:17:21 06.12.2014 22:17:14
krbtgt/f21.t...@ipa5.test
Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96 05.12.2014 22:17:17 06.12.2014 22:17:14
krbtgt/ipa5.t...@ipa5.test
Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
Of course, the fact that Kerberos tickets can get issued doesn't mean
that user can login and gain certain privileges. After all, SSSDs on IPA
hosts will not be able to map these Kerberos principals to anything
locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf
on each IPA host.
Patch attached.
--
/ Alexander Bokovoy
From d7d73e1e34aaa8c7042c332d09853a96955f6635 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Fri, 5 Dec 2014 21:22:23 +0200
Subject: [PATCH] WIP: ipa-kdb: when processing transitions, hand over unknown
ones to KDC
When processing cross-realm trust transitions, let the KDC to handle
those we don't know about. Admins might define the transitions as
explicit [capaths] in krb5.conf.
This is work-in-progress fix for
https://fedorahosted.org/freeipa/ticket/4791
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index a73a3cb..39fa583 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2680,7 +2680,8 @@ krb5_error_code ipadb_check_transited_realms(krb5_context
kcontext,
}
}
- ret = KRB5KRB_AP_ERR_ILL_CR_TKT;
+ /* Tell to KDC that we don't handle this transition so that rules in
krb5.conf could play its role */
+ ret = KRB5_PLUGIN_NO_HANDLE;
if (has_client_realm && has_transited_contents && has_server_realm) {
ret = 0;
}
--
2.1.0
--
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
