Re: [Freeipa-users] Cross-Realm authentification

2015-02-18 Thread Petr Spacek
On 5.12.2014 22:24, Petr Spacek wrote:
 On 5.12.2014 21:53, Alexander Bokovoy wrote:
 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] 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Andreas Ladanyi

 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 ?

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 ?



On my first kvno -S host hostname_in_foreign_domain i saw that the
temporary realm wasnt choosen correct. So i had to delete one REALM
entry in the domain_realm section to get kvno -S chooses the correct (
foreign ) temporary realm.




 [capaths]
 F21.TEST = {  IPA5.TEST = . }
 IPA5.TEST = {  F21.TEST = . }



 (on ipa-05-m.ipa5.test, realm IPA5.TEST):
 [root@ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r
 IPA5.TEST
 Authenticating as principal admin/ad...@ipa5.test with password.
 kadmin.local:  addprinc -requires_preauth krbtgt/F21.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:  addprinc -requires_preauth krbtgt/ipa5.t...@f21.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:  q

Ok, i see one difference: i didnt use the -requires_preauth flag. Why
did you use them ?
 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
 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Alexander Bokovoy

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] 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Alexander Bokovoy

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 -

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Andreas Ladanyi
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 :-)



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Petr Spacek
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?

-- 
Petr^2 Spacek

-- 
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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Alexander Bokovoy

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 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Alexander Bokovoy

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 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-05 Thread Petr Spacek
On 5.12.2014 21:53, Alexander Bokovoy wrote:
 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 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Andreas Ladanyi
Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:
 On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
 Hi,

 iam trying to setup a cross-realm relationship.

 Generated krbtgt cross-realm principals on both KDCs with the same
 password and kvno:

 krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
 krbtgt/REALM_A@REALM_B

 getprinc on REALM_A KDC for principal krbtgt/REALM_B@REALM_A:

 Number of keys: 4
 Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
 Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
 Key: vno 1, des3-cbc-sha1, Version 5
 Key: vno 1, arcfour-hmac, Version 5
 MKey: vno 1

 getprinc on REALM_A KDC for principal krbtgt/REALM_A@REALM_B:

 Number of keys: 4
 Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
 Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
 Key: vno 1, des3-cbc-sha1, Version 5
 Key: vno 1, arcfour-hmac, Version 5
 MKey: vno 1

 getprinc on REALM_B KDC for principal krbtgt/REALM_B@REALM_A:

 Number of keys: 6
 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
 Key: vno 1, DES cbc mode with CRC-32, no salt
 Key: vno 1, DES cbc mode with RSA-MD5, Version 4
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
 Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
 MKey: vno 1

 getprinc on REALM_B KDC for principal krbtgt/REALM_A@REALM_B:

 Number of keys: 6
 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
 Key: vno 1, DES cbc mode with CRC-32, no salt
 Key: vno 1, DES cbc mode with RSA-MD5, Version 4
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
 Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
 MKey: vno 1


 I set up the [capaths] section in the krb5.conf client config:

 [capaths]
 REALM_A = {
REALM_B = .
}
 REALM_B = {
REALM_A = .
}
 You need this section on both realm's KDCs.



I have done this now on all (2) KDCs without a restart of kerberos
service. The error message is the same like in my first mail.

-- 

Dipl.-Ing. (FH) Andreas Ladanyi

ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik
Karlsruher Institut für Technologie (KIT)

Am Fasanengarten 5, Gebäude 50.34, Raum 013
76131 Karlsruhe
Telefon: +49 721 608-43663

E-Mail: andreas.lada...@kit.edu

www.atis.informatik.kit.edu
www.kit.edu

KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum 
in der Helmholtz-Gemeinschaft




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Alexander Bokovoy

On Thu, 04 Dec 2014, Andreas Ladanyi wrote:

Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:

On Wed, 03 Dec 2014, Andreas Ladanyi wrote:

Hi,

iam trying to setup a cross-realm relationship.

Generated krbtgt cross-realm principals on both KDCs with the same
password and kvno:

krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
krbtgt/REALM_A@REALM_B

getprinc on REALM_A KDC for principal krbtgt/REALM_B@REALM_A:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_A KDC for principal krbtgt/REALM_A@REALM_B:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_B@REALM_A:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_A@REALM_B:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1


I set up the [capaths] section in the krb5.conf client config:

[capaths]
REALM_A = {
   REALM_B = .
   }
REALM_B = {
   REALM_A = .
   }

You need this section on both realm's KDCs.




I have done this now on all (2) KDCs without a restart of kerberos
service. The error message is the same like in my first mail.

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

[capaths]
F21.TEST = { 
 IPA5.TEST = . 
}
IPA5.TEST = { 
 F21.TEST = . 
}




(on ipa-05-m.ipa5.test, realm IPA5.TEST):
[root@ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r IPA5.TEST
Authenticating as principal admin/ad...@ipa5.test with password.
kadmin.local:  addprinc -requires_preauth krbtgt/F21.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:  addprinc -requires_preauth krbtgt/ipa5.t...@f21.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:  q

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:

[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 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Petr Spacek
On 4.12.2014 12:07, Alexander Bokovoy wrote:
 On Thu, 04 Dec 2014, Andreas Ladanyi wrote:
 Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:
 On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
 Hi,

 iam trying to setup a cross-realm relationship.

 Generated krbtgt cross-realm principals on both KDCs with the same
 password and kvno:

 krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
 krbtgt/REALM_A@REALM_B

 getprinc on REALM_A KDC for principal krbtgt/REALM_B@REALM_A:

 Number of keys: 4
 Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
 Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
 Key: vno 1, des3-cbc-sha1, Version 5
 Key: vno 1, arcfour-hmac, Version 5
 MKey: vno 1

 getprinc on REALM_A KDC for principal krbtgt/REALM_A@REALM_B:

 Number of keys: 4
 Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
 Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
 Key: vno 1, des3-cbc-sha1, Version 5
 Key: vno 1, arcfour-hmac, Version 5
 MKey: vno 1

 getprinc on REALM_B KDC for principal krbtgt/REALM_B@REALM_A:

 Number of keys: 6
 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
 Key: vno 1, DES cbc mode with CRC-32, no salt
 Key: vno 1, DES cbc mode with RSA-MD5, Version 4
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
 Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
 MKey: vno 1

 getprinc on REALM_B KDC for principal krbtgt/REALM_A@REALM_B:

 Number of keys: 6
 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
 Key: vno 1, DES cbc mode with CRC-32, no salt
 Key: vno 1, DES cbc mode with RSA-MD5, Version 4
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
 Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
 MKey: vno 1


 I set up the [capaths] section in the krb5.conf client config:

 [capaths]
 REALM_A = {
REALM_B = .
}
 REALM_B = {
REALM_A = .
}
 You need this section on both realm's KDCs.



 I have done this now on all (2) KDCs without a restart of kerberos
 service. The error message is the same like in my first mail.
 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
 
 [capaths]
 F21.TEST = {  IPA5.TEST = . }
 IPA5.TEST = {  F21.TEST = . }
 
 
 
 (on ipa-05-m.ipa5.test, realm IPA5.TEST):
 [root@ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r 
 IPA5.TEST
 Authenticating as principal admin/ad...@ipa5.test with password.
 kadmin.local:  addprinc -requires_preauth krbtgt/F21.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:  addprinc -requires_preauth krbtgt/ipa5.t...@f21.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:  q
 
 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:
 
 [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 

Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Alexander Bokovoy

On Thu, 04 Dec 2014, Petr Spacek wrote:

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'.


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.


Alexander, could you open a ticket to prevent us from forgetting about it?

I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
separate solution and it will be along the lines of existing 'ipa trust-add'
workflow where existing DAL driver code will work as it is.

--
/ 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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Simo Sorce
On Thu, 4 Dec 2014 13:22:01 +0200
Alexander Bokovoy aboko...@redhat.com wrote:

 On Thu, 04 Dec 2014, Petr Spacek wrote:
  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'.
 
 
  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.
 
 Alexander, could you open a ticket to prevent us from forgetting
 about it?
 I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
 separate solution and it will be along the lines of existing 'ipa
 trust-add' workflow where existing DAL driver code will work as it is.

I think we should have a way to relax this requirement, so that people
like Andreas can play with kerberos level trusts.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Petr Spacek
On 4.12.2014 16:58, Simo Sorce wrote:
 On Thu, 4 Dec 2014 13:22:01 +0200
 Alexander Bokovoy aboko...@redhat.com wrote:
 
 On Thu, 04 Dec 2014, Petr Spacek wrote:
 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'.


 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.

 Alexander, could you open a ticket to prevent us from forgetting
 about it?
 I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
 separate solution and it will be along the lines of existing 'ipa
 trust-add' workflow where existing DAL driver code will work as it is.
 
 I think we should have a way to relax this requirement, so that people
 like Andreas can play with kerberos level trusts.

I agree.

-- 
Petr^2 Spacek

-- 
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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Alexander Bokovoy

On Thu, 04 Dec 2014, Petr Spacek wrote:

On 4.12.2014 16:58, Simo Sorce wrote:

On Thu, 4 Dec 2014 13:22:01 +0200
Alexander Bokovoy aboko...@redhat.com wrote:


On Thu, 04 Dec 2014, Petr Spacek wrote:

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'.


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.


Alexander, could you open a ticket to prevent us from forgetting
about it?

I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
separate solution and it will be along the lines of existing 'ipa
trust-add' workflow where existing DAL driver code will work as it is.


I think we should have a way to relax this requirement, so that people
like Andreas can play with kerberos level trusts.


I agree.

Ok, then please file a ticket for this.
The change in the DAL driver will be a single line.
--
/ 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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-04 Thread Petr Spacek
On 4.12.2014 17:27, Alexander Bokovoy wrote:
 On Thu, 04 Dec 2014, Petr Spacek wrote:
 On 4.12.2014 16:58, Simo Sorce wrote:
 On Thu, 4 Dec 2014 13:22:01 +0200
 Alexander Bokovoy aboko...@redhat.com wrote:

 On Thu, 04 Dec 2014, Petr Spacek wrote:
 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'.


 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.

 Alexander, could you open a ticket to prevent us from forgetting
 about it?
 I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
 separate solution and it will be along the lines of existing 'ipa
 trust-add' workflow where existing DAL driver code will work as it is.

 I think we should have a way to relax this requirement, so that people
 like Andreas can play with kerberos level trusts.

 I agree.
 Ok, then please file a ticket for this.
 The change in the DAL driver will be a single line.

It would be better if you described the details in the ticket, but here it is:
https://fedorahosted.org/freeipa/ticket/4791

Please add missing information.

Have a nice weekend!

-- 
Petr^2 Spacek

-- 
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


Re: [Freeipa-users] Cross-Realm authentification

2014-12-03 Thread Alexander Bokovoy

On Wed, 03 Dec 2014, Andreas Ladanyi wrote:

Hi,

iam trying to setup a cross-realm relationship.

Generated krbtgt cross-realm principals on both KDCs with the same
password and kvno:

krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
krbtgt/REALM_A@REALM_B

getprinc on REALM_A KDC for principal krbtgt/REALM_B@REALM_A:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_A KDC for principal krbtgt/REALM_A@REALM_B:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_B@REALM_A:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_A@REALM_B:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1


I set up the [capaths] section in the krb5.conf client config:

[capaths]
REALM_A = {
   REALM_B = .
   }
REALM_B = {
   REALM_A = .
   }

You need this section on both realm's KDCs.


--
/ 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