Re: [Freeipa-users] Cross-Realm authentification
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] FreeIPA4 OTP vs PAM
On Sat, Nov 22, 2014 at 02:05:19PM -0800, Michael Lasevich wrote: I got some extra log output: seems that FAST IS being used. I am running SSSD 1.11.6, which is supposed to have above mentioned issues fixed: Log: = (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [find_principal_in_keytab] (0x4000): Trying to find principal host/ ipaclient.my.domain@my.domain.com in keytab. (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [match_principal] (0x1000): Principal matched to the sample (host/ ipaclient.my.domain@my.domain.com). (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361296: Retrieving host/ipaclient.my.domain@my.domain.com - krbtgt/ my.domain@my.domain.com from FILE:/var/lib/sss/db/ fast_ccache_MY.DOMAIN.COM with result: 0/Success (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [main] (0x0400): Will perform online auth (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [tgt_req_child] (0x1000): Attempting to get a TGT (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [get_and_save_tgt] (0x0400): Attempting kinit for realm [MY.DOMAIN.COM] (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361440: Getting initial credentials for mich...@my.domain.com (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361508: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361575: Retrieving host/ipaclient.my.domain@my.domain.com - krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM@X-CACHECONF: from FILE:/var/lib/sss/db/ fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361648: Sending request (188 bytes) to MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361842: Sending initial UDP request to dgram 1.1.1.2:88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.365901: Received answer from dgram 1.1.1.2:88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.365981: Response was from master KDC (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366020: Received error from KDC: -1765328359/Additional pre-authentication required (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366051: Upgrading to FAST due to presence of PA_FX_FAST in reply (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366075: Restarting to upgrade to FAST (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366102: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366161: Retrieving host/ipaclient.my.domain@my.domain.com - krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM@X-CACHECONF: from FILE:/var/lib/sss/db/ fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366191: Upgrading to FAST due to presence of PA_FX_FAST in reply (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366215: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366267: Retrieving host/ipaclient.my.domain@my.domain.com - krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM@X-CACHECONF: from FILE:/var/lib/sss/db/ fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366322: Getting credentials host/ipaclient.my.domain@my.domain.com - krbtgt/ my.domain@my.domain.com using ccache FILE:/var/lib/sss/db/ fast_ccache_MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451 [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366380: Retrieving host/ipaclient.my.domain@my.domain.com - krbtgt/ my.domain@my.domain.com from
Re: [Freeipa-users] Cross-Realm authentification
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
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
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] strange replica install error (another one)
On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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] strange replica install error (another one)
On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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] strange replica install error (another one)
Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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] strange replica install error (another one)
Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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
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
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
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] strange replica install error (another one)
On 12/04/2014 09:56 AM, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: Ok. This is yet a third issue - 1) crashes 2) high cpu 3) running out of FDs / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF Please see http://www.port389.org/docs/389ds/FAQ/performance-tuning.html#linux and http://www.port389.org/docs/389ds/howto/howto-systemd.html#increase-fd Note that nsslapd-maxdescriptors: 65535 is extremely high. I would not suggest going over 8192. Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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] strange replica install error (another one)
On Thu, 04 Dec 2014, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF As you said in the original messages that you are dealing with FreeIPA 4.0.5, it means you are on a system with systemd. For it to change limits you have to do it differently. See /lib/systemd/system/dirsrv@.service for detailed instructions. -- / 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] strange replica install error (another one)
On 12/4/14 8:30 AM, Alexander Bokovoy wrote: On Thu, 04 Dec 2014, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF As you said in the original messages that you are dealing with FreeIPA 4.0.5, it means you are on a system with systemd. For it to change limits you have to do it differently. See /lib/systemd/system/dirsrv@.service for detailed instructions. from /lib/systemd/system/dirsrv@.service -- # if you need to set other directives e.g. LimitNOFILE=8192 # set them in this file .include /etc/sysconfig/dirsrv.systemd And that is the file that contains the LimitNOFILE=32768 So that was done. But it still seems to not make any difference since ns-slapd itself is still code to 8192. That is the issue I am facing - I can get beyond 8192. (even if 65535 is not used - although that was the limit used with OpenLDAP and no issues) ~J -- 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] strange replica install error (another one)
On 12/04/2014 04:56 PM, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF there are two problems - how to increase the connetction table size in DS I would suggest to replace nsslapd-conntablesize and restart the server, the change is not dynamic - why you are running out of file descriptors you should query cn=monitor to check the effective tablesize and the number of established connections it could be a problem of clients not well behaving and not closing connections. you could set a low value of nsslapd-idletimeout to get rid of these connections Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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
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] strange replica install error (another one)
To help understand the environment a bit - perhaps this will help. 1. Approx 7500 clients across 3 datacenters- all manor of *nix, ranging from AIX, Linux, HP-UX and Solaris - hence the reason why they all can't use ipa-client configs. Although that is in the plan at least for Linux systems. 2. Servers/masters/replicas = 12 (4 each in 3 datacenters). Each DC has a primary CA so the replication agreements are between the 3 servers in each DC plus 1 server is a hot-spare and used strictly for replication to the other datacenters. 3. running out of FDs because there are 100s of jobs running across all the servers that do a lot of sudo and group lookups and more have to happen. Also, approx 1100 users accessing servers in vary random ways - but just using ssh/pssh/other-tools. Not sure if this helps - but perhaps? ~Janelle On 12/4/14 8:41 AM, Ludwig Krispenz wrote: On 12/04/2014 04:56 PM, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF there are two problems - how to increase the connetction table size in DS I would suggest to replace nsslapd-conntablesize and restart the server, the change is not dynamic - why you are running out of file descriptors you should query cn=monitor to check the effective tablesize and the number of established connections it could be a problem of clients not well behaving and not closing connections. you could set a low value of nsslapd-idletimeout to get rid of these connections Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with
Re: [Freeipa-users] strange replica install error (another one)
On 12/04/2014 11:01 AM, Janelle wrote: To help understand the environment a bit - perhaps this will help. 1. Approx 7500 clients across 3 datacenters- all manor of *nix, ranging from AIX, Linux, HP-UX and Solaris - hence the reason why they all can't use ipa-client configs. Although that is in the plan at least for Linux systems. 2. Servers/masters/replicas = 12 (4 each in 3 datacenters). Each DC has a primary CA so the replication agreements are between the 3 servers in each DC plus 1 server is a hot-spare and used strictly for replication to the other datacenters. 3. running out of FDs because there are 100s of jobs running across all the servers that do a lot of sudo and group lookups and more have to happen. Also, approx 1100 users accessing servers in vary random ways - but just using ssh/pssh/other-tools. This is what nscd/sssd/others are used for - to cache those client connections/loads to keep the load off of the server. Note that openldap uses epoll instead of poll() which is why it is better able to scale to 65k connections. 389 works well in environments where client caching is used. The use of 65k connections in 389 could explain the high CPU load, but we would need stacktraces to determine that (as in the aforementioned Debugging_Hangs). This still doesn't explain the crashing. Not sure if this helps - but perhaps? ~Janelle On 12/4/14 8:41 AM, Ludwig Krispenz wrote: On 12/04/2014 04:56 PM, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF there are two problems - how to increase the connetction table size in DS I would suggest to replace nsslapd-conntablesize and restart the server, the change is not dynamic - why you are running out of file descriptors you should query cn=monitor to check the effective tablesize and the number of established connections it could be a problem of clients not well behaving and not closing connections. you could set a low value of nsslapd-idletimeout to get rid of these connections Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK
[Freeipa-users] ad trust and default_domain_suffix
Hi,
I have a IDM (v3.3) installed on a Redhat7.
I have a IDM realm connected to an AD via trust relationship.
In the IDM realm there are Redhat6 and Redhat5 clients.
My client ask to be able to connect to the Linux machine with their AD without
entering their domain (just username). On Redhat 6 there is an option for sssd
(default_domain_suffix=)
Seems to be exactly what I need, but I have a problem. If I use this option, I
can indeed login with my AD username with domain name, but I cannot login with
my Linux IDM username anymore, even if I use my fully qualified username@realm.
i.e. In the middle of the PAM authentication it seems to fails (when ssh to the
machine with ssh server -l admin@realm, I get Write failed: Broken pipe).
If needed I can send more logs.
I reproduce the problem in a more simple environment: just a Linux realm, and
default_domain_suffix set to a inexistant domain, and again I cannot ssh to my
server with my fully qualified username@realm
Here is my sssd.conf:
[domain/idm1]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = idm1
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = dc.idm1
chpass_provider = ipa
ipa_server = dc.idm1
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2
domains = idm1
default_domain_suffix=toto.com
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
Here is my krb5.conf:
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = IDM1
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
default_ccache_name = KEYRING:persistent:%{uid}
ignore_acceptor_hostname = true
[realms]
IDM1 = {
kdc = dc.idm1:88
master_kdc = dc.idm1:88
admin_server = dc.idm1:749
default_domain = idm1
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.idm1 = IDM1
idm1 = IDM1
[dbmodules]
IDM1 = {
db_library = ipadb.so
}
is there something to add to make it working?
Site note: also with Redhat5 which is configured following ipa-advise
sssd-before-1.9, the default_domain_suffix is not understood with sssd1.9. Is
there a way to connect to force RHEL5 to let my windows user connect without
entering their domain. I don’t know if there is a way to tune the compatibility
tree return by the ldap server for example.
Or should I try to compile sssd 1.9 for RHEL5? (but I guess this is easier said
than done) or it doesn’t worth it? (incompatibility with kerberos, or with the
RHEL5 kernel…)
Regards,
Nicolas Zin
--
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] ad trust and default_domain_suffix
I answer to myself. (but my problem is not resolved) - Mail original - De: Nicolas Zin nicolas@savoirfairelinux.com À: freeipa-users@redhat.com Envoyé: Jeudi 4 Décembre 2014 18:49:36 Objet: [Freeipa-users] ad trust and default_domain_suffix Hi, I have a IDM (v3.3) installed on a Redhat7. I have a IDM realm connected to an AD via trust relationship. In the IDM realm there are Redhat6 and Redhat5 clients. My client ask to be able to connect to the Linux machine with their AD without entering their domain (just username). On Redhat 6 there is an option for sssd (default_domain_suffix=) Seems to be exactly what I need, but I have a problem. If I use this option, I can indeed login with my AD username with domain name, but I cannot login with my Linux IDM username anymore, even if I use my fully qualified username@realm. i.e. In the middle of the PAM authentication it seems to fails (when ssh to the machine with ssh server -l admin@realm, I get Write failed: Broken pipe). If needed I can send more logs. I reproduce the problem in a more simple environment: just a Linux realm, and default_domain_suffix set to a inexistant domain, and again I cannot ssh to my server with my fully qualified username@realm so when I try to do ssh localhost -l admin@idm1 (idm is my domain name), in the /var/log/sssd/sssd_nss.log I find: ... (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin@idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin@idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin@idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin@idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin@idm1] (Wed Dec 3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam_done] (0x0040): Invalid name received [admin] So it seems to be a problem with nss not able to find my user. Indeed, if I do a getent passwd admin it doesn't show anything, but if I do a getent passwd admin@idm1 it works. I found a workardound: getent passwd admin@idm1 /etc/passwd Now I can ssh to my server: ssh localhost -l admin@idm1 Is it a bug? is there a better workaround? Regards, -- 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
