From rmeggins at redhat.com Sat Nov 1 01:47:57 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Oct 2014 19:47:57 -0600 Subject: [Freeipa-users] stacktrace from crash In-Reply-To: <79cff3e4fcd14a0fba641bb844e5268b@BLUPR08MB488.namprd08.prod.outlook.com> References: <79cff3e4fcd14a0fba641bb844e5268b@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <54543BCD.5050609@redhat.com> On 10/31/2014 12:05 PM, Craig White wrote: > > OK ? and thanks to help in getting the debug-info packages installed > by Rich, I crashed IPA when trying to do an edit and have a stacktrace > from gdb. > > I?ll post it here unless someone thinks it would be better in a bug > report. > Thanks. This looks like https://fedorahosted.org/389/ticket/47889 We are preparing an errata release for RHEL 6.6 which should go out any day now. > 389-ds-base-1.2.11.15-47.el6.x86_64 > > openldap-2.4.39-8.el6.x86_64 > > db4-4.7.25-18.el6_4.x86_64 > > nss-3.16.1-14.el6.x86_64 > > nspr-4.10.6-1.el6_5.x86_64 > > ipa-server-3.0.0-42.el6.x86_64 > > slapi-nis-0.40-6.el6.x86_64 > > trying to only include relevant stuff ? just the threads that had an > errorbuf, let me know if I was trimmed too much. > > Core was generated by `/usr/sbin/ns-slapd -D > /etc/dirsrv/slapd-STT-LOCAL -i /var/run/dirsrv/s'. > > Program terminated with signal 11, Segmentation fault. > > #0 comp_cmp (s1=0xec60c0 "objectClass", s2=0x0) at > ldap/servers/slapd/attr.c:98 > > 98 while ( *s1 && *s1 != ';' && tolower( *s1 ) == > tolower( *s2 ) ) { > > Thread 44 (Thread 0x7f15df3f8700 (LWP 7490)): > > #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > > No symbol table info available. > > #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xac6de0) at > ../../../nspr/pr/src/pthreads/ptsynch.c:592 > > self = 139731916523264 > > #2 0x00007f15f64ec2a4 in ldbm_back_modify (pb=0x7f15b4033920) at > ldap/servers/slapd/back-ldbm/ldbm_modify.c:444 > > be = 0xb895b0 > > inst = 0xb82d10 > > li = 0xa65920 > > e = 0x0 > > ec = 0x0 > > original_entry = 0x0 > > tmpentry = 0x0 > > postentry = 0x0 > > mods = 0x7f15b403d6e0 > > mods_original = 0x0 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > txn = {back_txn_txn = 0x0} > > parent_txn = 0x0 > > ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, > attr_encrypt = 0} > > ruv_c_init = 0 > > retval = -1 > > msg = > > errbuf = 0x0 > > retry_count = 0 > > disk_full = 0 > > ldap_result_code = 0 > > ldap_result_message = 0x0 > > rc = 0 > > operation = 0x7f15b4038650 > > dblock_acquired = 0 > > addr = 0x7f15b4038728 > > is_fixup_operation = 0 > > is_ruv = 0 > > opcsn = 0x0 > > repl_op = 0 > > opreturn = 0 > > mod_count = 0 > > #3 0x00007f1600d20251 in op_shared_modify (pb=, > pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 > > rc = > > be = 0xb895b0 > > pse = > > referral = 0x0 > > e = > > dn = 0x7f15b403bc40 "uid= > SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" > > normdn = > > sdn = 0x7f15b4035480 > > passin_sdn = 1 > > mods = 0x7f15b403d6e0 > > pw_mod = > > tmpmods = 0x7f15b4014df0 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > repl_op = 0 > > internal_op = 32 > > lastmod = 1 > > skip_modified_attrs = 0 > > unhashed_pw_attr = 0x0 > > operation = 0x7f15b4038650 > > errorbuf = > "\000fff\000\177\000\000\320$\001\264\025\177\000\000\270\025?\337\025\177\000\000d\303\324\000\026\177\000\000\060\277\216\000\000\000\000\000 > \026?\337\025\177\000\000\001\000\000\000\000\000\000\000\350\357\000\264\025\177\000\000 at Q\001\264\025\177\000\000\247\303\324\000\026\177\000\000\240$\001\264\025\177\000\000\001\000\000\000\000\000\000\000 > \026?\337\025\177\000\000\261*\316\000\026\177\000\000` > \221\000\000\000\000\000\230\027?\337\025\177\000\000\000\000\000\000\000\000\000\000j,\316\000\026\177\000\000\300c\000\264\025\177\000\000\000\000\000\000\000\000\000\000entryusn\000estamp\000\340^\003\264\025\177\000\000\300c\000\264\025\177\000\000\340+\003\264\025\177\000\000\370\066?\337\025\177\000\000\000\000\000\000\ > > 000\000\000\000\005\t\316\000\026\177\000\000\060\277\216\000\000\000\000\000\340\026?\337\025\177\000\000"... > > err = > > lc_mod = > > p = > > i = > > proxydn = 0x0 > > proxy_err = > > errtext = 0x0 > > #4 0x00007f1600d20b31 in modify_internal_pb (pb=0x7f15b4033920) at > ldap/servers/slapd/modify.c:620 > > controls = 0x0 > > pwpolicy_ctrl = 0 > > op = 0x7f15b4038650 > > opresult = 0 > > normalized_mods = 0x7f15b4014df0 > > mods = 0x7f15b400f990 > > mod = > > smods = {mods = 0x1, num_elements = 13839236, num_mods = > 32534, iterator = 10968576, free_mods = 0} > > pw_change = > > old_pw = 0x0 > > #5 0x00007f15f5be133c in memberof_fix_memberof_callback (e= optimized out>, callback_data=) at > ldap/servers/plugins/memberof/memberof.c:2502 > > val = 0x0 > > mod_pb = 0x7f15b4033920 > > smod = 0x7f15b4037a20 > > mods = 0x7f15b400f990 > > hint = -1 > > rc = 0 > > sdn = 0x7f15b4035480 > > config = > > del_data = {dn = 0x0, type = 0x7f15b400f9d0 "memberOf"} > > groups = 0x7f15b400f920 > > #6 0x00007f15f5be1e20 in memberof_modop_one_replace_r (pb=0xc256b0, > config=0x7f15df3f3900, mod_op=1, group_sdn=0x7f15b400ce90, > op_this_sdn=, replace_with_sdn=0x0, > op_to_sdn=0x7f15b403b7e0, stack=0x0) at > ldap/servers/plugins/memberof/memberof.c:1340 > > rc = 0 > > mod = {mod_op = 9, mod_type = 0x2
, > mod_vals = {modv_strvals = 0x0, modv_bvals = 0x0}} > > replace_mod = {mod_op = -549505016, mod_type = 0x1000000b0 >
, mod_vals = {modv_strvals = 0x0, > modv_bvals = 0x0}} > > mods = {0x0, 0xa76818, 0x7f15df3f37f0} > > val = {0x7c0000005b
, > 0x6e00000077
} > > replace_val = {0x0, 0x3200000009
bounds>} > > mod_pb = 0x0 > > e = 0x7f15b4035480 > > ll = 0x0 > > op_str = > > op_to = 0x7f15b403bb90 > "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" > > op_this = > > to_dn_val = 0x7f15b4035b00 > > this_dn_val = 0x7f15b403b790 > > #7 0x00007f15f5be2f19 in memberof_modop_one_r (pb=0xc256b0, > config=0x7f15df3f3900, mod=1, group_sdn=0x7f15b400ce90, > smod=0x7f15b400faf0) at ldap/servers/plugins/memberof/memberof.c:1081 > > No locals. > > #8 memberof_modop_one (pb=0xc256b0, config=0x7f15df3f3900, mod=1, > group_sdn=0x7f15b400ce90, smod=0x7f15b400faf0) at > ldap/servers/plugins/memberof/memberof.c:1068 > > No locals. > > #9 memberof_mod_smod_list (pb=0xc256b0, config=0x7f15df3f3900, mod=1, > group_sdn=0x7f15b400ce90, smod=0x7f15b400faf0) at > ldap/servers/plugins/memberof/memberof.c:1462 > > dn_str = 0x7f15b4031660 > "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" > > bv = 0x7f15b4003820 > > last_size = 127 > > last_str = 0x7f15b4031660 > "uid=SOME_NAME,cn=users,cn=accounts,dc=stt,dc=local" > > sdn = 0x7f15b403b7e0 > > #10 0x00007f15f5be36a4 in memberof_del_smod_list (pb=0xc256b0) at > ldap/servers/plugins/memberof/memberof.c:1496 > > No locals. > > #11 memberof_postop_modify (pb=0xc256b0) at > ldap/servers/plugins/memberof/memberof.c:884 > > op = > > interested = > > type = 0x7f15b4016b20 "member" > > config_copied = > > mainConfig = > > configCopy = {groupattrs = 0x7f15b403d420, memberof_attr = > 0x7f15b400f9d0 "memberOf", allBackends = 0, group_filter = > 0x7f15b403d2a0, group_slapiattrs = 0x7f15b403b940} > > sdn = 0x7f15b400ce90 > > smods = 0x7f15b400fb10 > > smod = 0x7f15b400faf0 > > mods = 0x7f15b400efd0 > > next_mod = 0x7f15b400faf0 > > caller_id = 0x0 > > #12 0x00007f1600d2fb82 in plugin_call_func (list=0xa76220, > operation=505, pb=0xc256b0, call_one=0) at > ldap/servers/slapd/plugin.c:1453 > > n = > > func = 0x7f15f5be33b0 > > rc = > > return_value = > > count = > > #13 0x00007f1600d2fdcf in plugin_call_list (pb=0xc256b0, > whichfunction=505) at ldap/servers/slapd/plugin.c:1415 > > No locals. > > #14 plugin_call_plugins (pb=0xc256b0, whichfunction=505) at > ldap/servers/slapd/plugin.c:398 > > p = > > plugin_list_number = > > rc = 0 > > do_op = > > #15 0x00007f1600d202ec in op_shared_modify (pb=, > pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1098 > > rc = 0 > > be = 0xb895b0 > > pse = 0x7f15b4038ef0 > > referral = 0x0 > > e = > > dn = 0x7f15b4012160 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > normdn = > > sdn = 0x7f15b400ce90 > > passin_sdn = 0 > > mods = 0x7f15b4002470 > > pw_mod = > > tmpmods = 0x7f15b4016c30 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > repl_op = 0 > > internal_op = 0 > > lastmod = 1 > > skip_modified_attrs = 0 > > unhashed_pw_attr = 0x0 > > operation = 0xf66430 > > errorbuf = '\000' , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\023H?\337\025\177", > '\000' "\323, \313B", '\000' times>"\260, > Y?\337\025\177\000\000\000\000\000\000\000\000\000\000\200H?\337\025\177\000\000\333\313\023\377\025\177", > '\000' , " > H?\337\025\177\000\000\023H?\337\025\177\000\000\024H?\337\025\177\000\000\257G?\337\025\177\000\000\240G?\337\025\177\000\000!H?\337\025\177\000\000\000\000\000\000\006", > '\000' "\320, > .\000\264\025\177\000\000\000\000\000\000\000\000\000 ", '\000' > , > "?\000\264\025\177\000\000\240\344\237\000\000\000\000\000 > \307\372\000\026\177", '\000' , "103", '\000' > , "?\000\264\025\177"... > > err = > > lc_mod = > > p = > > i = > > proxydn = 0x0 > > proxy_err = > > errtext = 0x0 > > #16 0x00007f1600d2150e in do_modify (pb=0xc256b0) at > ldap/servers/slapd/modify.c:408 > > operation = 0xf66430 > > ber = > > last = 0x7f15b400d60b "" > > type = 0x0 > > tag = > > len = 18446744073709551615 > > mod = 0x0 > > mods = 0x7f15b400ce90 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > err = > > pw_change = 0 > > ignored_some_mods = > > has_password_mod = > > old_pw = 0x0 > > rawdn = 0x7f15b4012160 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > minssf_exclude_rootdse = > > normalized_mods = 0x7f15b4016c30 > > #17 0x0000000000414344 in connection_dispatch_operation () at > ldap/servers/slapd/connection.c:594 > > minssf = > > minssf_exclude_rootdse = > > #18 connection_threadmain () at ldap/servers/slapd/connection.c:2360 > > is_timedout = 0 > > curtime = > > pb = 0xc256b0 > > interval = 10000 > > conn = 0x7f15ec10d790 > > op = 0xf66430 > > tag = 102 > > need_wakeup = > > thread_turbo_flag = 0 > > ret = > > more_data = 0 > > replication_connection = > > doshutdown = 0 > > #19 0x00007f15ff154c93 in _pt_root (arg=0xf56ab0) at > ../../../nspr/pr/src/pthreads/ptthread.c:212 > > rv = > > thred = 0xf56ab0 > > detached = 1 > > id = 139731916523264 > > tid = 7490 > > #20 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 > > No symbol table info available. > > #21 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 > > No symbol table info available. > > Thread 32 (Thread 0x7f15d6bfd700 (LWP 7497)): > > #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > > No symbol table info available. > > #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xac6de0) at > ../../../nspr/pr/src/pthreads/ptsynch.c:592 > > self = 139731773937408 > > #2 0x00007f15f64ec2a4 in ldbm_back_modify (pb=0x7f15c0042160) at > ldap/servers/slapd/back-ldbm/ldbm_modify.c:444 > > be = 0xb895b0 > > inst = 0xb82d10 > > li = 0xa65920 > > e = 0x0 > > ec = 0x0 > > original_entry = 0x0 > > tmpentry = 0x0 > > postentry = 0x0 > > mods = 0x7f15c004ef80 > > mods_original = 0x0 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > txn = {back_txn_txn = 0x0} > > parent_txn = 0x0 > > ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, > attr_encrypt = 0} > > ruv_c_init = 0 > > retval = -1 > > msg = > > errbuf = 0x0 > > retry_count = 0 > > disk_full = 0 > > ldap_result_code = 0 > > ldap_result_message = 0x0 > > rc = 0 > > operation = 0x7f15c0016da0 > > dblock_acquired = 0 > > addr = 0x7f15c0016e78 > > is_fixup_operation = 0 > > is_ruv = 0 > > opcsn = 0x0 > > repl_op = 0 > > opreturn = 0 > > mod_count = 0 > > #3 0x00007f1600d20251 in op_shared_modify (pb=, > pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 > > rc = > > be = 0xb895b0 > > pse = > > referral = 0x0 > > e = > > dn = 0x7f15c000f990 > "uid=admin,cn=users,cn=accounts,dc=stt,dc=local" > > normdn = > > sdn = 0x7f15c004e360 > > passin_sdn = 0 > > mods = 0x7f15c004ef80 > > pw_mod = > > tmpmods = 0x7f15c004ef10 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > repl_op = 0 > > internal_op = 32 > > lastmod = 1 > > skip_modified_attrs = 0 > > unhashed_pw_attr = 0x0 > > operation = 0x7f15c0016da0 > > errorbuf = > "\000\000\000\000\000\000\000\000\235\001\324\000\026\177\000\000\060\000\005\300\025\177\000\000\256\000\000\000\000\000\000\000\251\000\000\000\000\000\000\000M&\323\352\257\006\024 > 8\000\000\000\000\000\000\000\016\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000`x\270\000\000\000\000\000\251\000\000\000\000\000\000\000\016\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000z\f\324\000\026\177\000\000@\351\326\000\026\177\000\000\021\377\323\000\026\177\000\000\300\364\244\000\000\000\000\000`x\270\000\000\000\000\000\300\364\244\000\000\000\000\000a", > '\000' , "\001h\210\277\326", '\000' times>"\360, > \225\310\000\000\000\000\000`x\270\000\000\000\000\000`x\270", '\000' > "\360, > E\311\000\000\000\000\000\060\253\277\326\025\177\000\000p\253\277\326\025\177\000\000`x\270", > '\000' "\360"... > > err = > > lc_mod = > > p = > > i = > > proxydn = 0x0 > > proxy_err = > > errtext = 0x0 > > #4 0x00007f1600d20b31 in modify_internal_pb (pb=0x7f15c0042160) at > ldap/servers/slapd/modify.c:620 > > controls = 0x0 > > pwpolicy_ctrl = 0 > > op = 0x7f15c0016da0 > > opresult = 0 > > normalized_mods = 0x7f15c004ef10 > > mods = 0x7f15c001dc40 > > mod = > > smods = {mods = 0x1, num_elements = 13839236, num_mods = > 32534, iterator = 10729216, free_mods = 0} > > pw_change = > > old_pw = 0x0 > > #5 0x00007f15f775fca7 in ipalockout_postop (pb=0xb87860) at > ipa_lockout.c:634 > > dn = 0x7f15c001f5a0 > "uid=admin,cn=users,cn=accounts,dc=stt,dc=local" > > policy_dn = 0xecc0c0 > "cn=global_policy,cn=STT.LOCAL,cn=kerberos,dc=stt,dc=local" > > target_entry = 0x7f15c000a040 > > policy_entry = 0x7f15c001db80 > > sdn = 0x7f15c0048440 > > pbtm = 0x7f15c0042160 > > smods = 0x7f15c0057db0 > > objectclass = 0x0 > > errstr = 0x0 > > ldrc = > > rc = 0 > > ret = 0 > > failedcount = 0 > > old_failedcount = 0 > > failedcountstr = > "p\253\277\326\025\177\000\000\315o\321\000\026\177\000\000\001\000\000\000\000\000\000\000po\001\300\025\177\000" > > failedstr = 0x7f15c0017bc0 "0" > > failed_bind = > > lockout_duration = > > max_fail = 3602884968 > > utctime = {tm_sec = 59, tm_min = 45, tm_hour = 17, tm_mday = > 31, tm_mon = 9, tm_year = 114, tm_wday = 5, tm_yday = 303, tm_isdst = > 0, tm_gmtoff = 0, tm_zone = 0x7f15fe8b2c07 "GMT"} > > time_now = 1414777559 > > timestr = "20141031174559Z" > > failcnt_interval = 3602884992 > > lastfail = 0x7f15c002e5e0 "20141031174346Z" > > tries = > > failure = 1 > > actual_type_name = 0x0 > > attr_free_flags = 0 > > values = 0x0 > > __func__ = "ipalockout_postop" > > #6 0x00007f1600d2fb82 in plugin_call_func (list=0xa3c4f0, > operation=501, pb=0xb87860, call_one=0) at > ldap/servers/slapd/plugin.c:1453 > > n = > > func = 0x7f15f775f5b0 > > rc = > > return_value = > > count = > > #7 0x00007f1600d2fdcf in plugin_call_list (pb=0xb87860, > whichfunction=501) at ldap/servers/slapd/plugin.c:1415 > > No locals. > > #8 plugin_call_plugins (pb=0xb87860, whichfunction=501) at > ldap/servers/slapd/plugin.c:398 > > p = > > plugin_list_number = > > rc = 0 > > do_op = > > #9 0x000000000040f41b in do_bind (pb=0xb87860) at > ldap/servers/slapd/bind.c:857 > > ber = > > err = > > isroot = 0 > > method = 163 > > version = 3 > > auth_response_requested = 0 > > pw_response_requested = 0 > > rawdn = 0x7f15c0017c60 "" > > dn = 0x7f15c0025cc0 "" > > saslmech = 0x7f15c005c790 "GSSAPI" > > cred = {bv_len = 618, bv_val = 0x7f15c002f430 > "`\202\002f\006\t*\206H\206\367\022\001\002\002\001"} > > be = 0x0 > > ber_rc = > > rc = 0 > > sdn = 0x7f15c005c760 > > bind_sdn_in_pb = 1 > > referral = 0xc000e690 > > errorbuf = > "\000\000\000\000\000\000\000\000@\337\000\300\000\000\000\000@\337\000\300\025\177\000\000 > \337\000\300\000\000\000\000\001\000\000\000\000\000\000\000`\254\277\326\025\177\000\000\000\000\000\000\000\000\000\000 > [\000\300\025\177\000\000C\021\326\000\026\177", '\000' times>"\366, > h\316\000\026\177\000\000\340R\366\000\000\000\000\000l\022\322\000\026\177\000\000\000\000\000\000\000\000\000\000\360o\000\300\025\177\000\000@\254\277\326\025\177\000\000`\254\277\326\025\177\000\000p\254\277\326\025\177", > '\000' , " \337\000\300\025\177", '\000' times>"\377, > \377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\067\000\300\025\177\000\000\220U\366\000\000\000\000\000\000\000\000\000\002", > '\000' , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\023\260\277\326\025\177", > '\000' "\351, \177\327\000"... > > supported = > > pmech = > > authtypebuf = > "X\356\360\000\000\000\000\000g\356\360\000\000\000\000\000\340?\326\025\177\000\000`\356\360\000\000\000\000\000\070?\326\025\177\000\000\004\000\000\000\000\000\000\000a\356\360\000\000\000\000\000g\356\360\000\000\000\000\000\002\001\001`\000\000\000\000M&\323\352\257\006\024 > h?\326\025\177\000\000\220\327\020\354\025\177\000\000X\315\277\326\025\177\000\000R8\317\377\025\177\000\000P\356\360\000\000\000\000\000\311\071\317\377\000\000\000\000\200\200\321", > '\000' , > "w\250\257\376\025\177\000\000\210?\326\025\177\000\000\b\000\000\000\000\000\000\000\360\225\310", > '\000' "\366, > h\316\000\026\177\000\000@\177\365\000\000\000\000\000\343`\325\000\026\177\000\000\060J\310", > '\000' , > "\001\000\000\000\000\000\000\000\202\366\023\377\025\177\000" > > bind_target_entry = 0x0 > > auto_bind = > > minssf = > > minssf_exclude_rootdse = > > #10 0x0000000000414453 in connection_dispatch_operation () at > ldap/servers/slapd/connection.c:569 > > minssf = > > minssf_exclude_rootdse = > > #11 connection_threadmain () at ldap/servers/slapd/connection.c:2360 > > is_timedout = 0 > > curtime = > > pb = 0xb87860 > > interval = 10000 > > conn = 0x7f15ec10d790 > > op = 0xc895f0 > > tag = 96 > > need_wakeup = > > thread_turbo_flag = 0 > > ret = > > more_data = 0 > > replication_connection = > > doshutdown = 0 > > #12 0x00007f15ff154c93 in _pt_root (arg=0xf57f40) at > ../../../nspr/pr/src/pthreads/ptthread.c:212 > > rv = > > thred = 0xf57f40 > > detached = 1 > > id = 139731773937408 > > tid = 7497 > > #13 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 > > No symbol table info available. > > #14 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 > > No symbol table info available. > > Thread 11 (Thread 0x7f15ca3e9700 (LWP 7517)): > > #0 0x00007f15feafb5bc in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > > No symbol table info available. > > #1 0x00007f15ff14e863 in PR_EnterMonitor (mon=0xc5ddc0) at > ../../../nspr/pr/src/pthreads/ptsynch.c:592 > > self = 139731564140288 > > #2 0x00007f15f5be3565 in memberof_postop_modify (pb=0xf6ab10) at > ldap/servers/plugins/memberof/memberof.c:859 > > op = > > interested = > > type = 0x7f15c0047790 "member" > > config_copied = > > mainConfig = > > configCopy = {groupattrs = 0x7f15c00429e0, memberof_attr = > 0x7f15c005bee0 "memberOf", allBackends = 0, group_filter = > 0x7f15c004cfb0, group_sla > > piattrs = 0x7f15c00429b0} > > sdn = 0x7f15c0047980 > > smods = 0x7f15c005b9a0 > > smod = 0x7f15c005bba0 > > mods = 0x7f15c00424e0 > > next_mod = 0x7f15c005bba0 > > caller_id = 0x0 > > #3 0x00007f1600d2fb82 in plugin_call_func (list=0xa76220, > operation=505, pb=0xf6ab10, call_one=0) at > ldap/servers/slapd/plugin.c:1453 > > n = > > func = 0x7f15f5be33b0 > > rc = > > return_value = > > count = > > #4 0x00007f1600d2fdcf in plugin_call_list (pb=0xf6ab10, > whichfunction=505) at ldap/servers/slapd/plugin.c:1415 > > No locals. > > #5 plugin_call_plugins (pb=0xf6ab10, whichfunction=505) at > ldap/servers/slapd/plugin.c:398 > > p = > > plugin_list_number = > > rc = 0 > > do_op = > > #6 0x00007f1600d202ec in op_shared_modify (pb=, > pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1098 > > rc = 0 > > be = 0xb895b0 > > pse = 0x7f15c00242d0 > > referral = 0x0 > > e = > > dn = 0x7f15c004ea00 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > normdn = > > sdn = 0x7f15c0047980 > > passin_sdn = 0 > > mods = 0x7f15c0047cb0 > > pw_mod = > > tmpmods = 0x7f15c002dd70 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > repl_op = 0 > > internal_op = 0 > > lastmod = 1 > > skip_modified_attrs = 0 > > unhashed_pw_attr = 0x0 > > operation = 0xf5ea80 > > errorbuf = '\000' , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377CU>\312\025\177", > '\000' , "Y\177\327\000\026\177", '\000' times>"\340, > f>\312\025\177\000\000\000\000\000\000\000\000\000\000\260U>\312\025\177\000\000\333\313\023\377\025\177", > '\000' , > "PU>\312\025\177\000\000CU>\312\025\177\000\000DU>\312\025\177\000\000\337T>\312\025\177\000\000\320T>\312\025\177\000\000QU>\312\025\177\000\000\000\000\000\000\024", > '\000' , > "0\033\001\300\025\177\000\000\000\000\000\000\000\000\000 ", '\000' > , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\242W>\312\025\177", > '\000' , "90\000\000\000\000b\372B", '\000' 21 times>... > > err = > > lc_mod = > > p = > > i = > > proxydn = 0x0 > > proxy_err = > > errtext = 0x0 > > #7 0x00007f1600d2150e in do_modify (pb=0xf6ab10) at > ldap/servers/slapd/modify.c:408 > > operation = 0xf5ea80 > > ber = > > last = 0x7f15c00255a9 "" > > type = 0x0 > > tag = > > len = 18446744073709551615 > > mod = 0x0 > > mods = 0x7f15c0047980 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > err = > > pw_change = 0 > > ignored_some_mods = > > has_password_mod = > > old_pw = 0x0 > > rawdn = 0x7f15c004ea00 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > minssf_exclude_rootdse = > > normalized_mods = 0x7f15c002dd70 > > #8 0x0000000000414344 in connection_dispatch_operation () at > ldap/servers/slapd/connection.c:594 > > minssf = > > minssf_exclude_rootdse = > > #9 connection_threadmain () at ldap/servers/slapd/connection.c:2360 > > is_timedout = 0 > > curtime = > > pb = 0xf6ab10 > > interval = 10000 > > conn = 0x7f15ec10d790 > > op = 0xf5ea80 > > tag = 102 > > need_wakeup = > > thread_turbo_flag = 0 > > ret = > > more_data = 0 > > replication_connection = > > doshutdown = 0 > > #10 0x00007f15ff154c93 in _pt_root (arg=0xf5ba00) at > ../../../nspr/pr/src/pthreads/ptthread.c:212 > > rv = > > thred = 0xf5ba00 > > detached = 1 > > id = 139731564140288 > > tid = 7517 > > #11 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 > > No symbol table info available. > > #12 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 > > No symbol table info available. > > Thread 1 (Thread 0x7f15d07f3700 (LWP 7507)): > > #0 comp_cmp (s1=0xec60c0 "objectClass", s2=0x0) at > ldap/servers/slapd/attr.c:98 > > No locals. > > #1 0x00007f1600ce1675 in slapi_attr_type_cmp (a1=0xec60c0 > "objectClass", a2=0x0, opt=) at > ldap/servers/slapd/attr.c:131 > > rc = 0 > > #2 0x00007f1600d00dd2 in test_ava_filter (pb=0x0, e=0x7f15bc02ab20, > a=0x7f15bc0c31e0, ava=0xee8590, ftype=163, verify_access=0, > only_check_access=0, a > > ccess_check_done=0x7f15d07ee4e8) at ldap/servers/slapd/filterentry.c:342 > > rc = > > #3 0x00007f1600d5ff2d in vattr_test_filter (pb=0xf6a230, > e=0x7f15bc02ab20, f=0xee8570, filter_type=, > type=0xec60c0 "objectClass") at ldap/servers/slapd/vattr.c:605 > > acl_test_done = 0 > > rc = -1 > > sp_bit = 0 > > list = > > sdn = > > be = > > namespace_dn = > > #4 0x00007f1600d013fe in slapi_vattr_filter_test_ext_internal > (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee8570, verify_access=0, > only_check_access=0, access_check_done=0x7f15d07ee64c) at > ldap/servers/slapd/filterentry.c:897 > > rc = > > #5 0x00007f1600d018e5 in vattr_test_filter_list (pb=0xf6a230, > e=0x7f15bc02ab20, flist=, ftype=161, > verify_access=0, only_check_access=0, > access_check_done=0x7f15d07ee64c) at ldap/servers/slapd/filterentry.c:1038 > > nomatch = > > f = 0xee8570 > > #6 0x00007f1600d0153d in slapi_vattr_filter_test_ext_internal > (pb=0xf6a230, e=0x7f15bc02ab20, f=0xee2500, verify_access=0, > only_check_access=0, access_check_done=0x7f15d07ee64c) at > ldap/servers/slapd/filterentry.c:965 > > rc = 0 > > #7 0x00007f1600d0181c in slapi_vattr_filter_test_ext (pb=0xf6a230, > e=0x7f15bc02ab20, f=0xee2500, verify_access=0, > only_check_access=) at > ldap/servers/slapd/filterentry.c:827 > > rc = 0 > > access_check_done = 0 > > #8 0x00007f15f7b6ecb5 in dna_be_txn_pre_op (pb=0xf6a230, > modtype=) at ldap/servers/plugins/dna/dna.c:3478 > > config_entry = 0xef0ff0 > > e = 0x7f15bc02ab20 > > smods = 0x7f15bc009a60 > > smod = > > next_mod = 0x0 > > attr = 0x0 > > mods = 0x7f15bc0af2b0 > > bv = > > list = > > value = 0x0 > > types_to_generate = 0x0 > > generated_types = 0x0 > > new_value = 0x0 > > errstr = 0x0 > > dn = 0x7f15bc0c22f0 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > type = > > numvals = > > e_numvals = 0 > > i = > > len = > > ret = 0 > > #9 0x00007f1600d2fb82 in plugin_call_func (list=0xa2fe00, > operation=461, pb=0xf6a230, call_one=0) at > ldap/servers/slapd/plugin.c:1453 > > n = > > func = 0x7f15f7b6f680 > > rc = > > return_value = > > count = > > #10 0x00007f1600d2fdcf in plugin_call_list (pb=0xf6a230, > whichfunction=461) at ldap/servers/slapd/plugin.c:1415 > > No locals. > > #11 plugin_call_plugins (pb=0xf6a230, whichfunction=461) at > ldap/servers/slapd/plugin.c:398 > > p = > > plugin_list_number = > > rc = 0 > > do_op = > > #12 0x00007f15f64ecd27 in ldbm_back_modify (pb=0xf6a230) at > ldap/servers/slapd/back-ldbm/ldbm_modify.c:599 > > cache_rc = 0 > > new_mod_count = 0 > > be = 0xb895b0 > > inst = 0xb82d10 > > li = 0xa65920 > > e = 0x7f15c004be40 > > ec = 0x7f15bc01ef10 > > original_entry = 0x7f15bc0c3d90 > > tmpentry = 0x0 > > postentry = 0x0 > > mods = 0x7f15bc026930 > > mods_original = 0x7f15bc021c20 > > smods = {mods = 0x7f15bc026930, num_elements = 5, num_mods = > 4, iterator = 0, free_mods = 0} > > txn = {back_txn_txn = 0x7f15bc0b4290} > > parent_txn = 0x0 > > ruv_c = {old_entry = 0x0, new_entry = 0x0, smods = 0x0, > attr_encrypt = 0} > > ruv_c_init = 0 > > retval = 0 > > msg = > > errbuf = 0x0 > > retry_count = > > disk_full = 0 > > ldap_result_code = 0 > > ldap_result_message = 0x0 > > rc = 0 > > operation = 0xc707a0 > > dblock_acquired = 1 > > addr = 0xc70878 > > is_fixup_operation = 0 > > is_ruv = 0 > > opcsn = > > repl_op = 0 > > opreturn = 0 > > mod_count = 4 > > #13 0x00007f1600d20251 in op_shared_modify (pb=, > pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1061 > > rc = > > be = 0xb895b0 > > pse = > > referral = 0x0 > > e = > > dn = 0x7f15bc0c2940 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > normdn = > > sdn = 0x7f15bc0af3b0 > > passin_sdn = 0 > > mods = 0x7f15bc0c35c0 > > pw_mod = > > tmpmods = 0x7f15bc0c38c0 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > repl_op = 0 > > internal_op = 0 > > lastmod = 1 > > skip_modified_attrs = 0 > > unhashed_pw_attr = 0x0 > > operation = 0xc707a0 > > errorbuf = '\000' , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377C\365~\320\025\177", > '\000' , "Y\177\327\000\026\177", '\000' times>"\340, > \006\177\320\025\177\000\000\000\000\000\000\000\000\000\000\260\365~\320\025\177\000\000\333\313\023\377\025\177", > '\000' , > "P\365~\320\025\177\000\000C\365~\320\025\177\000\000D\365~\320\025\177\000\000\337\364~\320\025\177\000\000\320\364~\320\025\177\000\000Q\365~\320\025\177\000\000\000\000\000\000\024", > '\000' "\200, > \262\000\274\025\177\000\000\000\000\000\000\000\000\000 ", '\000' > , > "h\304\023\377\025\177\000\000\000\000\000\000\377\377\377\377\242\367~\320\025\177", > '\000' , "90\000\000\000\000b\372B", '\000' 21 times>, "@\t\177\320\025\177\000\000"... > > err = > > lc_mod = > > p = > > i = > > proxydn = 0x0 > > proxy_err = > > errtext = 0x0 > > #14 0x00007f1600d2150e in do_modify (pb=0xf6a230) at > ldap/servers/slapd/modify.c:408 > > operation = 0xc707a0 > > ber = > > last = 0x7f15bc0bb197 "" > > type = 0x0 > > tag = > > len = 18446744073709551615 > > mod = 0x0 > > mods = 0x7f15bc0af3b0 > > smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator > = 0, free_mods = 0} > > err = > > pw_change = 0 > > ignored_some_mods = > > has_password_mod = > > old_pw = 0x0 > > rawdn = 0x7f15bc0c2940 "cn=Join Systems to Domain and > DNS,cn=roles,cn=accounts,dc=stt,dc=local" > > minssf_exclude_rootdse = > > normalized_mods = 0x7f15bc0c38c0 > > #15 0x0000000000414344 in connection_dispatch_operation () at > ldap/servers/slapd/connection.c:594 > > minssf = > > minssf_exclude_rootdse = > > #16 connection_threadmain () at ldap/servers/slapd/connection.c:2360 > > is_timedout = 0 > > curtime = > > pb = 0xf6a230 > > interval = 10000 > > conn = 0x7f15ec10d790 > > op = 0xc707a0 > > tag = 102 > > need_wakeup = > > thread_turbo_flag = 0 > > ret = > > more_data = 0 > > replication_connection = > > doshutdown = 0 > > #17 0x00007f15ff154c93 in _pt_root (arg=0xf59ca0) at > ../../../nspr/pr/src/pthreads/ptthread.c:212 > > rv = > > thred = 0xf59ca0 > > detached = 1 > > id = 139731669038848 > > tid = 7507 > > #18 0x00007f15feaf79d1 in start_thread () from /lib64/libpthread.so.0 > > No symbol table info available. > > #19 0x00007f15fe8449dd in clone () from /lib64/libc.so.6 > > No symbol table info available. > > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From gregor.bregenzer at gmail.com Sun Nov 2 13:33:58 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Sun, 2 Nov 2014 14:33:58 +0100 Subject: [Freeipa-users] FreeIPA AD Trust: password policy? Message-ID: Hi! I have FreeIPA 4.0.1 with an trust to AD to Windows 2012. The Linux clients have sssd 1.11.6 and use the ipa provider for authentication (part of client sssd.conf): id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = linux1.linux.intern chpass_provider = ipa I found out, the password policy for complexity etc. is retrieved from the group policy in AD, but is there also a way to retrieve the password policy from FreeIPA? All the other parts such as sudo rules and HBAC work when i assign the FreeIPA posix group which includes the external group from AD, but not the password policy. Is there also some documentation about password policy with AD trust (i was browsing documents from http://www.freeipa.org/page/Trusts but did not find anything)? Thanks! Gregor From abokovoy at redhat.com Sun Nov 2 17:05:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 2 Nov 2014 19:05:37 +0200 Subject: [Freeipa-users] FreeIPA AD Trust: password policy? In-Reply-To: References: Message-ID: <20141102170537.GN4107@redhat.com> On Sun, 02 Nov 2014, Gregor Bregenzer wrote: >Hi! > >I have FreeIPA 4.0.1 with an trust to AD to Windows 2012. The Linux >clients have sssd 1.11.6 and use the ipa provider for authentication >(part of client sssd.conf): > >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = linux1.linux.intern >chpass_provider = ipa > > >I found out, the password policy for complexity etc. is retrieved from >the group policy in AD, but is there also a way to retrieve the >password policy from FreeIPA? All the other parts such as sudo rules >and HBAC work when i assign the FreeIPA posix group which includes the >external group from AD, but not the password policy. Authentication is handled by AD in this case, thus password policy is handled by AD DCs as well. There is no way to attach IPA-specific password policy to AD users because the actual password policy check is done on AD side without us being involved in any decision. >Is there also some documentation about password policy with AD trust >(i was browsing documents from http://www.freeipa.org/page/Trusts but >did not find anything)? Since we don't have ways to handle it, there is no documentation. The same situation would be with any Kerberos cross-realm trust -- the final decision on password changes is done by the KDC that is responsible for the Kerberos principal in question. -- / Alexander Bokovoy From deanhunter at comcast.net Sun Nov 2 17:33:42 2014 From: deanhunter at comcast.net (Dean Hunter) Date: Sun, 02 Nov 2014 11:33:42 -0600 Subject: [Freeipa-users] Password Change from Gnome Desktop Message-ID: <1414949622.2621.3.camel@comcast.net> Am I blind? When I try to change my own password as an IPA user from the Users applet Gnome desktop (3.12.2-1.fc20), changes are not allowed to the password. I can change the language, but not the password. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregor.bregenzer at gmail.com Sun Nov 2 18:52:12 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Sun, 2 Nov 2014 19:52:12 +0100 Subject: [Freeipa-users] FreeIPA AD Trust: password policy? In-Reply-To: <20141102170537.GN4107@redhat.com> References: <20141102170537.GN4107@redhat.com> Message-ID: Thanks! :-) Gregor 2014-11-02 18:05 GMT+01:00 Alexander Bokovoy : > On Sun, 02 Nov 2014, Gregor Bregenzer wrote: >> >> Hi! >> >> I have FreeIPA 4.0.1 with an trust to AD to Windows 2012. The Linux >> clients have sssd 1.11.6 and use the ipa provider for authentication >> (part of client sssd.conf): >> >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = linux1.linux.intern >> chpass_provider = ipa >> >> >> I found out, the password policy for complexity etc. is retrieved from >> the group policy in AD, but is there also a way to retrieve the >> password policy from FreeIPA? All the other parts such as sudo rules >> and HBAC work when i assign the FreeIPA posix group which includes the >> external group from AD, but not the password policy. > > Authentication is handled by AD in this case, thus password policy is > handled by AD DCs as well. There is no way to attach IPA-specific > password policy to AD users because the actual password policy check is > done on AD side without us being involved in any decision. > >> Is there also some documentation about password policy with AD trust >> (i was browsing documents from http://www.freeipa.org/page/Trusts but >> did not find anything)? > > Since we don't have ways to handle it, there is no documentation. The > same situation would be with any Kerberos cross-realm trust -- the final > decision on password changes is done by the KDC that is responsible for > the Kerberos principal in question. > -- > / Alexander Bokovoy From john.obaterspok at gmail.com Sun Nov 2 18:54:10 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sun, 2 Nov 2014 19:54:10 +0100 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> Message-ID: Hello, Now I'm able to access samba network share from Win PC using my ipa user & password. But I need to enter it each time. I have still not been able to logon to Win7 PC with my IPA user. Currently I get "No mapping between account names and security IDs was done" when I try to login. What I've done is this: 1. Created a dns entry for winpc + a host entry in web-ui, 2. On the IPA server I ran "ipa-getkeytab -s -p host/ -e arcfour-hmac -k krb5.keytab. -P What I'm I suppose to do with the krb5.keytab. file? Can't see any mention of this? On the Win PC I did: 1. ksetup /setdomain [REALM NAME] 2. ksetup /addkdc [REALM NAME] [ipa.fqdn] 3. ksetup /addkpasswd [REALM NAME] [ipa.fqdn] 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] 5. ksetup /mapuser * * -- john 2014-10-29 22:01 GMT+01:00 Loris Santamaria : > El mi?, 29-10-2014 a las 21:40 +0100, John Obaterspok escribi?: > > Hello, > > > > > > I've tried this as well. My IPA is not connected to an AD. My smb.conf > > looks almost the same. The differences are: > > - I got the default workgroup set (MY or something) > > - No FILE:/ prefix for keytab file > > > > > > I had the samba and ipserver on the same box so I just had to add the > > cifs server and get keytab file in the same way. > > I was a bit surprised to see that accessing samba using "smbclient -k > > \\..." worked right away from a linux box. Then stopped working if I > > did kdestroy. > > > > > > But, I never got it to work from Windows. The Windows PC is not joined > > to any AD, it uses MIT Kerb client 4.0.1 and I successfully get tickes > > and can sshlogin via putty without password. > > > > > > Any ideas on how to get this going from Windows as well? > > I guess you should prepare the ipa server for a windows domain trust > (even if you won't setup any trust with an ad domain), with > ipa-adtrust-install. Beware that it will overwrite your smb.conf. > > With that configuration and the steps described in > http://www.redhat.com/archives/freeipa-users/2013-September/msg00226.html > you will be able to use the native windows kerberos libraries and you > should be able to open a samba share with your kerberos credentials. > > Best regards > > > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Sun Nov 2 20:51:42 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Sun, 02 Nov 2014 16:21:42 -0430 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> Message-ID: <1414961502.5014.21.camel@toron.pzo.lgs.com.ve> El dom, 02-11-2014 a las 19:54 +0100, John Obaterspok escribi?: > I have still not been able to logon to Win7 PC with my IPA user. > Currently I get "No mapping between account names and security IDs was > done" when I try to login. > What I've done is this: > 1. Created a dns entry for winpc + a host entry in web-ui, > 2. On the IPA server I ran "ipa-getkeytab -s -p > host/ -e arcfour-hmac -k krb5.keytab. -P > What I'm I suppose to do with the krb5.keytab. file? Can't see > any mention of this? > On the Win PC I did: > 1. ksetup /setdomain [REALM NAME] > 2. ksetup /addkdc [REALM NAME] [ipa.fqdn] > 3. ksetup /addkpasswd [REALM NAME] [ipa.fqdn] > 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] > 5. ksetup /mapuser * * The keytab is not needed, you just have to generate it to set a password for the computer. You are supposed to use the same password in ipa-getkeytab and in the "ksetup /setcomputerpassword" commands -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From william.muriithi at gmail.com Sun Nov 2 21:58:07 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 2 Nov 2014 16:58:07 -0500 Subject: [Freeipa-users] Renewing FreeIPA 2.2 certificate Message-ID: Afternoon I have been trying to renew FreeIPA certificate for the last three days and I am running out of luck. I can't for example use the GUI interface and the ipa cli tools are also failing since the certificate expired on 27th last month. I have followed the instructions below but may be missing a step. http://www.freeipa.org/page/IPA_2x_Certificate_Renewal Below is what I have done. I seem to have renewed some certificate successfully. [root at ipa1-yyz-int 10.30.2014]# cat certificate_status.sh #!/bin/bash for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do echo $nickname certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after done [root at ipa1-yyz-int 10.30.2014]# ./certificate_status.sh auditSigningCert cert-pki-ca Not After : Thu Apr 23 22:18:47 2015 ocspSigningCert cert-pki-ca Not After : Fri Oct 14 22:17:47 2016 subsystemCert cert-pki-ca Not After : Fri Oct 14 22:17:47 2016 Server-Cert cert-pki-ca Not After : Fri Oct 14 22:17:48 2016 I think I have done the steps above correctly but dont understand this section [root at ipa1-yyz-int 10.30.2014]# certutil -L -d /etc/httpd/alias -n ipaCert Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=EXAMPLE.LOC" Validity: Not Before: Tue Nov 06 21:35:53 2012 Not After : Mon Oct 27 21:35:53 2014 As you can see below, this certificate was not renewed, and therefore I couldnt change the serial # through ldap tools. Which step would I have missed, or rather what should I re-run? Would be grateful for a second eye looking at it and advice what I could be missing. I know I am using old software and did setup a replica successfully on Friday but it also have certificate issues. I plan to move all the certificate role to the free-IPA 3 once I get the certificate issues sorted and decommission Free-IPA 2.2 William From rcritten at redhat.com Sun Nov 2 23:08:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 02 Nov 2014 18:08:15 -0500 Subject: [Freeipa-users] Renewing FreeIPA 2.2 certificate In-Reply-To: References: Message-ID: <5456B95F.4000800@redhat.com> William Muriithi wrote: > Afternoon > > I have been trying to renew FreeIPA certificate for the last three > days and I am running out of luck. I can't for example use the GUI > interface and the ipa cli tools are also failing since the certificate > expired on 27th last month. I have followed the instructions below > but may be missing a step. > > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > > Below is what I have done. I seem to have renewed some certificate > successfully. > > > [root at ipa1-yyz-int 10.30.2014]# cat certificate_status.sh #!/bin/bash > > for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert > cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > echo $nickname > certutil -L -d /var/lib/pki-ca/alias -n "${nickname}" | grep -i after > done > > > [root at ipa1-yyz-int 10.30.2014]# ./certificate_status.sh > auditSigningCert cert-pki-ca > Not After : Thu Apr 23 22:18:47 2015 ocspSigningCert cert-pki-ca > Not After : Fri Oct 14 22:17:47 2016 subsystemCert cert-pki-ca > Not After : Fri Oct 14 22:17:47 2016 Server-Cert cert-pki-ca > Not After : Fri Oct 14 22:17:48 2016 > > > I think I have done the steps above correctly but dont understand this section > > [root at ipa1-yyz-int 10.30.2014]# certutil -L -d /etc/httpd/alias -n ipaCert > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 7 (0x7) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=EXAMPLE.LOC" > Validity: > Not Before: Tue Nov 06 21:35:53 2012 > Not After : Mon Oct 27 21:35:53 2014 > > As you can see below, this certificate was not renewed, and therefore > I couldnt change the serial # through ldap tools. Which step would I > have missed, or rather what should I re-run? > > > Would be grateful for a second eye looking at it and advice what I > could be missing. > > I know I am using old software and did setup a replica successfully on > Friday but it also have certificate issues. I plan to move all the > certificate role to the free-IPA 3 once I get the certificate issues > sorted and decommission Free-IPA 2.2 Is certmonger tracking the certificate? Run this to see: # getcert list -d /etc/httpd/alias -n ipaCert If so then try this: # getcert resubmit -d /etc/httpd/alias -n ipaCert This will only work if you've updated the renewed certificates in CS.cfg and you've fixed the NSS database trust for the audit cert. If/once that is renewed then you can do the other steps. rob From roman at naumenko.ca Mon Nov 3 03:20:13 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Sun, 02 Nov 2014 22:20:13 -0500 Subject: [Freeipa-users] Multiple organizations on one server Message-ID: <5456F46D.1060304@naumenko.ca> Hi, Similar question was asked already, " Limiting group/user visibility" at https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html but other than this I couldn't find any clues if that's possible. If I was to manage separate organizations with own users, computers and other entries in one ipa server - would such scenario be possible? Thanks, --Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Mon Nov 3 07:00:24 2014 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 3 Nov 2014 08:00:24 +0100 Subject: [Freeipa-users] Woes adding a samba server to the ipa domain In-Reply-To: <1414961502.5014.21.camel@toron.pzo.lgs.com.ve> References: <1413810952.3012.22.camel@toron.pzo.lgs.com.ve> <5445B498.9090608@redhat.com> <1413893951.3184.15.camel@toron.pzo.lgs.com.ve> <20141023103255.GA2826@localhost.localdomain> <1414612459.3112.22.camel@toron.pzo.lgs.com.ve> <1414616519.3112.28.camel@toron.pzo.lgs.com.ve> <1414961502.5014.21.camel@toron.pzo.lgs.com.ve> Message-ID: 2014-11-02 21:51 GMT+01:00 Loris Santamaria : > El dom, 02-11-2014 a las 19:54 +0100, John Obaterspok escribi?: > > > > I have still not been able to logon to Win7 PC with my IPA user. > > Currently I get "No mapping between account names and security IDs was > > done" when I try to login. > > The keytab is not needed, you just have to generate it to set a password > for the computer. > Is this the same as the "Set One Time Password" action under enrollment in the web ui? > You are supposed to use the same password in ipa-getkeytab and in the > "ksetup /setcomputerpassword" commands > > Cough, cough. I just noticed that the Win PC I was experimenting with had Windows Home edition. It seems you need at least Pro/Ultimate editions to join a domain. -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Nov 3 10:39:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Nov 2014 11:39:43 +0100 Subject: [Freeipa-users] Third party SSL certificate renewal In-Reply-To: References: <544A5028.70100@redhat.com> Message-ID: <54575B6F.5050509@redhat.com> Hi Dragan, first of all sorry for the delay, I was on leave last week. Dne 24.10.2014 v 20:31 Dragan Prostran napsal(a): > Hi Jan, > > I'm grateful for your help. I've researched how to follow your > recommendations above, but I'm not having a lot of luck. According to > old posts in this mailing list, > https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html, > the command ipa-server-certinstall is the way to go. That said, I > found an issue you've filed to allow for this, and it was implemented > in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641 > Unfortunately, this system is running FreeIPA 3.0: > > # rpm -qa | grep -P "ipa[_-]" > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-client-3.0.0-26.el6_4.4.x86_64 > ipa-admintools-3.0.0-26.el6_4.4.x86_64 > libipa_hbac-1.9.2-82.10.el6_4.x86_64 > libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 > ipa-python-3.0.0-26.el6_4.4.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > # > > I've found these instructions: > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read > those instructions, and I believe I may have a misconception about > this process. The procedure calls to: > # cp /root/ipa.crt /usr/share/ipa/html/ca.crt > # cp /root/ipa.crt /etc/ipa/ca.crt > > Can you clear up what /root/ipa.crt ought to contain? I assume it > ought to contain *only* the root CA certificate which is the *first* > key in the bundle provided by the 3rd party Certificate Authority. Is > that correct? The instructions you have found do not apply entirely in your situation. The file /etc/ipa/ca.crt should contain only the *leaf* CA cert, i.e. the one with subject name equal to issuer name in your LDAP/HTTP server certs. The file /usr/share/ipa/html/ca.crt should contain the whole CA cert chain. > > The files /etc/ip/ca.crt already exists, but it is a single > certificate. The file I have, issued alongside with the certificate by > GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a > single file. Could you please be more detailed as to how to accomplish > this: "you need to import the CA certificate to NSS databases at > /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and > /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and > /usr/share/ipa/html/ca.crt and update > cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it." Once you have the correct CA cert in /etc/ipa/ca.crt, you can run the following command to import the cert to each NSS database: # certutil -d -A -n -t C,, -a -i /etc/ipa/ca.crt (use any nickname you like) For the LDAP update, see "Update the CA in LDAP" in the instructions you have found. > > I certainly hope these are not inappropriate questions: I'd just like > to ensure this is done correctly. Thank you. Don't worry, these are very appropriate questions ;-) > > --- > Dragan Prostran > > On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a): >> >>> Hello, >>> >>> This is my first time posting to this list, so if I've made a faux pas >>> or mistake, please do correct me. >>> >>> Can anyone please point me to the correct method to renewing 3rd party >>> SSL certificates used by FreeIPA 3.0? I suspect I've not done this >>> correctly. >>> >>> Here is what has worked correctly so far: >>> 1. FreeIPA is installed and configured to work correctly. It uses 3rd >>> party SSL certificates. I have access to the CSR, the certificate, the >>> private key, and the new CA bundle. >>> 2. I have successfully followed these instructions to update the SSL >>> certificates used by Apache to serve the FreeIPA web interface: >>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. >>> Of note is that there are 2 IPA servers, and the procedure has been >>> followed on both. >>> 3. Upon visiting the FreeIPA web interface, I can see that the >>> certificate is valid, and expires in the future. Login to FreeIPA and >>> modifying (for example) an LDAP password, work correctly. >>> 4. 3rd party services that take advantage of LDAP work correctly. I >>> can login and authenticate via LDAP. >>> >>> Here is what does not work correctly: >>> 1. A distinct, 3rd party webservice that takes advantage of LDAP *via >>> SSL* no longer is able to authenticate. Prior to certificate update >>> mentioned, this did work correctly. I must admit I'm unfamiliar with >>> LDAP (via SSL), and so instead of troubleshooting that service, I had >>> a closer look at the FreeIPA instance. >> >> >> The 3rd party webservice needs to trust the CA certificate of the LDAP >> server certificate in order for this to work. >> >>> 2. When connected to the FreeIPA instance, and issuing 'ipa >>> user-status username', the following error is returned: >>> >>> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain >>> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate >>> issuer has been marked as not trusted by the user.) >>> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain >>> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate >>> issuer has been marked as not trusted by the user.) >>> ipa: ERROR: cannot connect to Gettext('any of the configured servers', >>> domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml, >>> https://IPA2_FQDN_REDACTED/ipa/xml >>> >>> Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been >>> renewed. Of note is that, prior to the certificate update noted above, >>> this did work correctly, and would return the status of the user. >> >> >> This means that the CA certificate of the HTTP server certificate is missing >> from the NSS database at /etc/pki/nssdb. >> >> >>> >>> Further, when issuing 'ipa service restart' on the IPA instance, the >>> following is returned: >>> >>> # service ipa restart >>> Restarting Directory Service >>> Shutting down dirsrv: >>> DIRSRV_REDACTED... [ OK ] >>> Starting dirsrv: >>> DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert: >>> CERT_VerifyCertificateNow: verify certificate failed for cert >>> CERT_CN_REDACTED - GoDaddy.com, Inc. of family >>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 >>> - Peer's certificate issuer has been marked as not trusted by the >>> user.) >>> [ OK ] >>> Restarting KDC Service >>> Stopping Kerberos 5 KDC: [ OK ] >>> Starting Kerberos 5 KDC: [ OK ] >>> Restarting KPASSWD Service >>> Stopping Kerberos 5 Admin Server: [ OK ] >>> Starting Kerberos 5 Admin Server: [ OK ] >>> Restarting MEMCACHE Service >>> Stopping ipa_memcached: [ OK ] >>> Starting ipa_memcached: [ OK ] >>> Restarting HTTP Service >>> Stopping httpd: [ OK ] >>> Starting httpd: [ OK ] >>> # >> >> >> This means that the CA certificate of the LDAP server certificate is missing >> from the NSS database at /etc/dirsrv/slapd-DIRSRV_REDACTED. >> >>> >>> Can anyone instruct me as to what may be misconfigured? I assume this >>> is the root cause of LDAP via SSL not working correctly, but I'm not >>> quite sure how to verify that. >>> It is of note to say that the CA bundle (a chain of public keys >>> leading to a root, 3rd party CA) issued with the new certificate is >>> different from the previous certificate bundle. I know this as I have >>> records of the original certificate, key, bundle, and CSR. The CA >>> bundle issued with this new certificate is *different* from the CA >>> bundle used with the original certificate. As I have not provided, or >>> otherwise used, this new CA bundle when renewing the certificates in >>> FreeIPA, I suspect this is the root cause of the error, and so I ask >>> for help here. >> >> >> You are right this is the root cause. To fix IPA, you need to import the CA >> certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, >> /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and >> /usr/share/ipa/html/ca.crt and update >> cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it. >> >>> >>> --- >>> Dragan Prostran >>> >> >> Honza >> >> -- >> Jan Cholasta > > > -- Jan Cholasta From natxo.asenjo at gmail.com Mon Nov 3 12:07:23 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 3 Nov 2014 13:07:23 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: <5447CFAE.2040206@redhat.com> References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> Message-ID: hi, I have been really busy, apologies for the delay in answering. On Wed, Oct 22, 2014 at 5:39 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo wrote: >>> But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I >>> still get the old crl dated june 28th last year. >>> >>> Should I modify ipa-pki-proxy.conf as well on the CRL generator host >>> to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>> as well? >> >> This morning the /ipa/crl dir still had the lists of 28th June 2013 in >> the crl generator host. In my test environment running centos 7 the >> files get updated, so I think a process is nut running. But which one? >> >> Going to the /ca/ee/ca/getCRL?op=getCRL& >> crlIssuingPoint=MasterCRL gives me the up to date CRL. >> >> -- >> Groeten, >> natxo >> > > To enable CRL generation you need these set: > > ca.crl.MasterCRL.enableCRLCache=false > ca.crl.MasterCRL.enableCRLUpdates=false ok, this is in the host holding the CRL, right? (in my case kdc01, the first one). I followed the guide in http://www.freeipa.org/page/CVE-2012-4546 where in point 2a of manual instructions you can read true. I have changed that now. to false and restarted the pki-cad daemon. > Given that the CA seems to be generating a new CRL that you can fetch > directly I'll assume those are set. > The CA also needs configuration on how/where to publish a file-based > CRL. The configuration should look like: > > ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin > ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish > ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true > ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher > ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime > ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false > ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true > ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher These values are correct. How often does the crl list get generated? i still do not see recent data. Thanks! -- Groeten, natxo From roman at naumenko.ca Mon Nov 3 12:20:46 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Mon, 03 Nov 2014 07:20:46 -0500 Subject: [Freeipa-users] Multiple organizations on one server In-Reply-To: <5456F46D.1060304@naumenko.ca> References: <5456F46D.1060304@naumenko.ca> Message-ID: <5457731E.6040103@naumenko.ca> Roman Naumenko said the following, on 02-11-14, 22:20: > Hi, > > Similar question was asked already, " Limiting group/user visibility" > at > https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html > but other than this I couldn't find any clues if that's possible. > > If I was to manage separate organizations with own users, computers > and other entries in one ipa server - would such scenario be possible? I found relevant information, at least about directory structure, in red hat directory server docs: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes Since RH package is based on 389 directory server, which is part of freeipa - I wonder if its possible to maintain independent root suffixes? --Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Nov 3 12:37:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Nov 2014 14:37:08 +0200 Subject: [Freeipa-users] Multiple organizations on one server In-Reply-To: <5457731E.6040103@naumenko.ca> References: <5456F46D.1060304@naumenko.ca> <5457731E.6040103@naumenko.ca> Message-ID: <20141103123708.GO4107@redhat.com> On Mon, 03 Nov 2014, Roman Naumenko wrote: >Roman Naumenko said the following, on 02-11-14, 22:20: >>Hi, >> >>Similar question was asked already, " Limiting group/user >>visibility" at https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html >>but other than this I couldn't find any clues if that's possible. >> >>If I was to manage separate organizations with own users, computers >>and other entries in one ipa server - would such scenario be >>possible? >I found relevant information, at least about directory structure, in >red hat directory server docs: >https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes > >Since RH package is based on 389 directory server, which is part of >freeipa - I wonder if its possible to maintain independent root >suffixes? While 389-ds does support multiple root suffixes, FreeIPA management tools, Kerberos DAL driver, access control setup and other components do not support multi-tenancy. -- / Alexander Bokovoy From roman at naumenko.ca Mon Nov 3 12:43:17 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Mon, 03 Nov 2014 07:43:17 -0500 Subject: [Freeipa-users] Multiple organizations on one server In-Reply-To: <20141103123708.GO4107@redhat.com> References: <5456F46D.1060304@naumenko.ca> <5457731E.6040103@naumenko.ca> <20141103123708.GO4107@redhat.com> Message-ID: <54577865.7090701@naumenko.ca> Alexander Bokovoy said the following, on 03-11-14, 7:37: > On Mon, 03 Nov 2014, Roman Naumenko wrote: >> Roman Naumenko said the following, on 02-11-14, 22:20: >>> Hi, >>> >>> Similar question was asked already, " Limiting group/user >>> visibility" at >>> https://www.redhat.com/archives/freeipa-users/2011-November/msg00277.html >>> but other than this I couldn't find any clues if that's possible. >>> >>> If I was to manage separate organizations with own users, computers >>> and other entries in one ipa server - would such scenario be possible? >> I found relevant information, at least about directory structure, in >> red hat directory server docs: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Configuring_Directory_Databases.html#Configuring_Directory_Databases-Creating_and_Maintaining_Suffixes >> >> >> Since RH package is based on 389 directory server, which is part of >> freeipa - I wonder if its possible to maintain independent root >> suffixes? > While 389-ds does support multiple root suffixes, FreeIPA management > tools, Kerberos DAL driver, access control setup and other components do > not support multi-tenancy. Thank you for clarification. --Roman From simo at redhat.com Mon Nov 3 14:41:45 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 3 Nov 2014 09:41:45 -0500 Subject: [Freeipa-users] Password Change from Gnome Desktop In-Reply-To: <1414949622.2621.3.camel@comcast.net> References: <1414949622.2621.3.camel@comcast.net> Message-ID: <20141103094145.0ffa8141@willson.usersys.redhat.com> On Sun, 02 Nov 2014 11:33:42 -0600 Dean Hunter wrote: > Am I blind? When I try to change my own password as an IPA user from > the Users applet Gnome desktop (3.12.2-1.fc20), changes are not > allowed to the password. I can change the language, but not the > password. Sounds like a bug in Gnome Accounts stuff, can you change your password in a terminal using "passwd" ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Nov 3 16:21:29 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Nov 2014 11:21:29 -0500 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> Message-ID: <5457AB89.9080506@redhat.com> Natxo Asenjo wrote: > hi, > > I have been really busy, apologies for the delay in answering. > > On Wed, Oct 22, 2014 at 5:39 PM, Rob Crittenden wrote: >> Natxo Asenjo wrote: >>> On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo wrote: >>>> But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I >>>> still get the old crl dated june 28th last year. >>>> >>>> Should I modify ipa-pki-proxy.conf as well on the CRL generator host >>>> to point to the /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL >>>> as well? >>> >>> This morning the /ipa/crl dir still had the lists of 28th June 2013 in >>> the crl generator host. In my test environment running centos 7 the >>> files get updated, so I think a process is nut running. But which one? >>> >>> Going to the /ca/ee/ca/getCRL?op=getCRL& >>> crlIssuingPoint=MasterCRL gives me the up to date CRL. >>> >>> -- >>> Groeten, >>> natxo >>> >> >> To enable CRL generation you need these set: >> >> ca.crl.MasterCRL.enableCRLCache=false >> ca.crl.MasterCRL.enableCRLUpdates=false > > ok, this is in the host holding the CRL, right? (in my case kdc01, the > first one). I followed the guide in > http://www.freeipa.org/page/CVE-2012-4546 where in point 2a of manual > instructions you can read true. I have changed that now. to false and > restarted the pki-cad daemon. ok > >> Given that the CA seems to be generating a new CRL that you can fetch >> directly I'll assume those are set. > >> The CA also needs configuration on how/where to publish a file-based >> CRL. The configuration should look like: >> >> ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin >> ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish >> ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true >> ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher >> ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime >> ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false >> ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 >> ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false >> ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true >> ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher > > These values are correct. > > How often does the crl list get generated? i still do not see recent data. This is controlled by ca.crl.MasterCRL.autoUpdateInterval which by default is 240, so every 4 hours. rob From andreas.ladanyi at kit.edu Tue Nov 4 12:24:53 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Tue, 04 Nov 2014 13:24:53 +0100 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP In-Reply-To: <20141013170522.32b3dc8d@willson.usersys.redhat.com> References: <543BF032.3000103@kit.edu> <20141013170522.32b3dc8d@willson.usersys.redhat.com> Message-ID: <5458C595.6010001@kit.edu> > On Mon, 13 Oct 2014 17:30:58 +0200 > Andreas Ladanyi wrote: > >> On my old system from which i migrated the users/group accounts uses >> the Kerberos own DB without LDAP for the principals. >> >> I could dump the master key : >> >> kdb5_util dump filename K/M at REALM >> >> Now i have a lot of numbers in the dumpfile. Which number belongs to >> which LDAP attribute in the (test) FreeIPA 389 LDAP System (Simon >> called it a throwaway system :-) ) >> >> I dont know the data structure of the KRB own DB. > And you shouldn't really care, you should use the kdb5 utils to load > back the dumped DB, provided you first create all users and hosts and > services via the freeipa tools. > > Simo. Ok, i dumped the kerberos DB with kdb5_util and get the dumped file with all principals. So now if i unterstand you correctly, if have to create all users/group/service principals with the freeipa tools first ? How can i import the dumped principals in to the 389 LDAP ? I cant see any options in the kdb5_ldap_util to import the principals and hashes from the dumped KRB DB file to 389 LDAP ? Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5306 bytes Desc: S/MIME Cryptographic Signature URL: From natxo.asenjo at gmail.com Tue Nov 4 12:39:07 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 4 Nov 2014 13:39:07 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: <5457AB89.9080506@redhat.com> References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> Message-ID: hi, On Mon, Nov 3, 2014 at 5:21 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> How often does the crl list get generated? i still do not see recent data. > > This is controlled by ca.crl.MasterCRL.autoUpdateInterval which by > default is 240, so every 4 hours. mmm, still no new items in the https://kdc01.sub.domain.tld/ipa/crl/ site. Everything is stuck on june 28 2013. Oh well, I can use mod_rewrite to send it to /ca/ee/ca/getCRL?op=getCRL& >> crlIssuingPoint=MasterCRL where you get the latest crl. Thanks, -- Groeten, natxo From simo at redhat.com Tue Nov 4 13:42:36 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 4 Nov 2014 08:42:36 -0500 Subject: [Freeipa-users] Migrate KRB DB hashes to IPA LDAP In-Reply-To: <5458C595.6010001@kit.edu> References: <543BF032.3000103@kit.edu> <20141013170522.32b3dc8d@willson.usersys.redhat.com> <5458C595.6010001@kit.edu> Message-ID: <20141104084236.0418c809@willson.usersys.redhat.com> On Tue, 04 Nov 2014 13:24:53 +0100 Andreas Ladanyi wrote: > > On Mon, 13 Oct 2014 17:30:58 +0200 > > Andreas Ladanyi wrote: > > > >> On my old system from which i migrated the users/group accounts > >> uses the Kerberos own DB without LDAP for the principals. > >> > >> I could dump the master key : > >> > >> kdb5_util dump filename K/M at REALM > >> > >> Now i have a lot of numbers in the dumpfile. Which number belongs > >> to which LDAP attribute in the (test) FreeIPA 389 LDAP System > >> (Simon called it a throwaway system :-) ) > >> > >> I dont know the data structure of the KRB own DB. > > And you shouldn't really care, you should use the kdb5 utils to load > > back the dumped DB, provided you first create all users and hosts > > and services via the freeipa tools. > > > > Simo. > > Ok, i dumped the kerberos DB with kdb5_util and get the dumped file > with all principals. > > So now if i unterstand you correctly, if have to create all > users/group/service principals with the freeipa tools first ? > > How can i import the dumped principals in to the 389 LDAP ? I cant > see any options in the kdb5_ldap_util to import the principals and > hashes from the dumped KRB DB file to 389 LDAP ? Sorry Andreas I misremembered how it was done. You can use kdb5_util, to import too. In this old piece of code you can find some hints about how to use it: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipa-admintools/ipa-change-master-key?h=ipa-1-2 This one was used to enact a change of master key, you do not need to do that, so just look at how the import back is done around line 300. You will also probably need to use the '-x ipa-setup-override-restrictions' option. Keep in mind that I have NOT tested this procedure, it may work or it may fatally cripple your setup. At a minimum I strongly suggest you exclude the services tied to the IPA Servers themselves. Take good backups before attempting this. Simo. -- Simo Sorce * Red Hat, Inc * New York From skupko.sk at gmail.com Tue Nov 4 08:48:34 2014 From: skupko.sk at gmail.com (Peter Viskup) Date: Tue, 4 Nov 2014 09:48:34 +0100 Subject: [Freeipa-users] [bug report] IPA failing to start Message-ID: Hi all, don't want to register on FreeIPA nor RedHat/CentOS ticketing systems, but want to make others know about my discovery. Hope somebody will review it and open bug report. The IPA (Kerberos part) failing to start when supported_enctypes = aes camellia -des3 -des -rc4 listed in kdc.conf for realm. With listing supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal camellia256-cts-cmac:normal camellia128-cts-cmac:normal -des -des3 -rc4 the Kerberos and IPA start successfully. These are the installed and affected versions ipa-server-3.3.3-28.el7.centos.1.x86_64 krb5-server-1.11.3-49.el7.x86_64 krb5-libs-1.11.3-49.el7.x86_64 Hope it will help somebody. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 4 14:17:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Nov 2014 09:17:30 -0500 Subject: [Freeipa-users] adding replication agreements In-Reply-To: References: , <545259E2.9020703@redhat.com> Message-ID: <5458DFFA.3070908@redhat.com> Shashi Dahal wrote: > Hi Rob, > > From server A and server B(itself), if I give that command, i get: > > last update status: -1 - LDAP error: Can't contact LDAP server I'd start with checking basic connectivity to ensure that A/B can talk to port 389 on C. > From server C, I get: > Cannot find cab0558.sdn1.ams1.spil in public server list This suggests that even C doesn't think it is a master. # ipa-replica-manage list On C will show what it thinks is the list of available masters. I'd also look at the replication agreements that C has: # ldapsearch -x -D 'cn=directory manager' -W -b 'cn=mapping tree,cn=config' rob > Please let me know what steps to do next. I am completely lost. > > > Thanks, > Shashi > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, October 30, 2014 4:31 PM > To: Shashi Dahal; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] adding replication agreements > > Shashi Dahal wrote: >> Hi, >> >> I have ipa master server: A >> and I have 2 ipa replicas: B and C >> >> >> replica B crashed, so it was deleted from A and recreated using >> ipa-replica-parepare to generate the file and set it up from there. >> >> >> in server A B and C, if I do ipa-replica-manage list >> >> serverA lists A B and C as master >> serverB lists A B and C as master >> serverC lists only A and C as master .. B is missing. >> >> trying the command ipa-replica-manage connect B from serverC >> gives: You cannot connect to a previously deleted master >> >> >> now how do I add trust relationship between C and B ? > > I changed the subject as this isn't trust, it's replication. I don't > want to be pedantic but there is a significant difference. > > What I'd do, on each master, is this: > > ipa-replica-manage list -v `hostname` > > I think you'll find that C isn't getting updates. The masters list is > stored in LDAP so if C doesn't know that B exists it likely means that > its data is stale. > > rob > From rob.verduijn at gmail.com Tue Nov 4 14:27:10 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 4 Nov 2014 15:27:10 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> Message-ID: Hello again, I've managed to integrate my katello configuration with freeipa. Now I not only use freeipa authentication in katello but also when a host is defined in katello it automagically gets created in the freeipa realm , certs, otp,dns all working great. however, to obtain all this integration greatness I had to downgrade my freeipa to 3.3.5 again (revert snapshot) because the katello realm integration tool (foreman-prepare-realm) is not capable of dealing with 4.X versions of freeipa. And now the named-pkcs11 again does not see my internal zones. This page https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart thinks I should contact the freeipa-users list The command 'ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. and the command 'ipa-ldap-updater' didn't fix it either. So I am now stuck at freeipa 3.3.5 again (with a working katello integration, so I got some mixed emotions about it) Any ideas anyone ? Rob 2014-10-29 22:14 GMT+01:00 Rob Verduijn : > Hello, > > I've tested the update again. > > The bind-utils conflict is still there when I issue "yum update > freeipa-server" ( as indicated on the freeipa 4.1 download page > http://www.freeipa.org/page/Downloads#Upgrading ) > > 'yum update' works fine > > My internal zones didn't resolv after the update > ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't fix > it > ipa-ldap-updater did fix the 'access control instructions' and my internal > dns zones started to resolv again :-) > > Cheers > Rob > > > 2014-10-29 18:14 GMT+01:00 Petr Spacek : > >> On 29.10.2014 16:46, Rob Verduijn wrote: >> >>> Hello, >>> >>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>> fixes the problem. >>> >>> I can resolv my internal dns zones again:-) >>> >>> Many thanx. >>> >>> Since this problem happened every time I tried to update the freeipa >>> server. >>> I could re-run the update with some debug options if you like so you can >>> pinpoint what goes wrong with the update script if you like. >>> >> >> I have re-build some packages in mkosek's CORP so now you should not see >> encounter dependency problems. Simple 'yum upgrade' should give you all the >> required packages. >> >> We are looking at other problems in upgrade process right now so there is >> not much to test except package dependencies. >> >> -- >> Petr^2 Spacek >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 4 14:52:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Nov 2014 15:52:43 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> Message-ID: <5458E83B.8040601@redhat.com> On 4.11.2014 15:27, Rob Verduijn wrote: > Hello again, > > I've managed to integrate my katello configuration with freeipa. > Now I not only use freeipa authentication in katello but also when a host > is defined in katello it automagically gets created in the freeipa realm , > certs, otp,dns all working great. > > however, to obtain all this integration greatness I had to downgrade my > freeipa to 3.3.5 again (revert snapshot) because the katello realm > integration tool (foreman-prepare-realm) is not capable of dealing with 4.X > versions of freeipa. It would be nice if you could get tell us more details about the problem you had with Katello, AFAIK we are not aware of any. > And now the named-pkcs11 again does not see my internal zones. > > This page > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart thinks > I should contact the freeipa-users list Do I understand correctly that you did all the steps 0-4 successfully and then you found out that you can't see DNS objects in LDAP (step 5) when using ldapsearch with DNS principal? Can you see the objects in IPA web UI or CLI? If it is the case then we will need help from LDAP ACI expert (pviktori? :-). Petr^2 Spacek > The command 'ipa-ldap-updater > /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. > and the command 'ipa-ldap-updater' didn't fix it either. > > So I am now stuck at freeipa 3.3.5 again (with a working katello > integration, so I got some mixed emotions about it) > Any ideas anyone ? > Rob > > > > > > > 2014-10-29 22:14 GMT+01:00 Rob Verduijn : > >> Hello, >> >> I've tested the update again. >> >> The bind-utils conflict is still there when I issue "yum update >> freeipa-server" ( as indicated on the freeipa 4.1 download page >> http://www.freeipa.org/page/Downloads#Upgrading ) >> >> 'yum update' works fine >> >> My internal zones didn't resolv after the update >> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't fix >> it >> ipa-ldap-updater did fix the 'access control instructions' and my internal >> dns zones started to resolv again :-) >> >> Cheers >> Rob >> >> >> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >> >>> On 29.10.2014 16:46, Rob Verduijn wrote: >>> >>>> Hello, >>>> >>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>> fixes the problem. >>>> >>>> I can resolv my internal dns zones again:-) >>>> >>>> Many thanx. >>>> >>>> Since this problem happened every time I tried to update the freeipa >>>> server. >>>> I could re-run the update with some debug options if you like so you can >>>> pinpoint what goes wrong with the update script if you like. >>>> >>> >>> I have re-build some packages in mkosek's CORP so now you should not see >>> encounter dependency problems. Simple 'yum upgrade' should give you all the >>> required packages. >>> >>> We are looking at other problems in upgrade process right now so there is >>> not much to test except package dependencies. >>> >>> -- >>> Petr^2 Spacek From roman at naumenko.ca Tue Nov 4 14:58:50 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 4 Nov 2014 09:58:50 -0500 (EST) Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <6912624.145341.1415112964441.JavaMail.root@naumenko.ca> Message-ID: <18057653.145376.1415113130392.JavaMail.root@naumenko.ca> Hi, I'm planning to use FreeIPA to manage infrastructure resources, sudo users, DNS and things like that. But I also need isp style directory with multiple organizations and root DNs to control users, mainly for authentication purpose. FreeIPA wouldn't suitable for latter, so I'm looking at OpenDJ or Centos DS for that. Could you advise what would be the most suitable product in this case? And what the difference between RedHat and Centos versions of directory servers? --Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From guigne at lms.polytechnique.fr Tue Nov 4 15:18:11 2014 From: guigne at lms.polytechnique.fr (=?UTF-8?B?RWRvdWFyZCBHdWlnbsOp?=) Date: Tue, 04 Nov 2014 16:18:11 +0100 Subject: [Freeipa-users] Sync from AD towards FreeIPA directory server Message-ID: <5458EE33.3010604@lms.polytechnique.fr> Hello FreeIPA Users, I am trying to make working a sync between my AD win 2008 R2 and FreeIPA (fedora 20) server. My goal is to retrieve all my AD users in freeIPA database. 1. With "ipa-replica-manage connect --winsync ...", I succeeded to copy users from AD to FreeIPA (via the sync agreement) But passwords have not been sync. I had to reinit password in IPA to enable user login in the freeipa domain. Is it a normal issue ? Is there any way to sync password ? 2. I tried then to sync posix attributes (from my AD which has "Subsystem for UNIX-based Applications") into the freeIPA server with activating the posix winsync plugin I would like to extract attributes from my AD like : - uidNumber - gidNumber - unixHomeDirectory - loginShell - msSFU30NisDomain With posix winsync activated, the sync do not work at all... no AD users sync. What is missing to enable it ? I follow the documentation here http://www.port389.org/docs/389ds/design/winsync-posix.html And enable the plugin this way : ldapmodify -D "cn=directory manager" -w xxxxx dn: cn=Posix Winsync API,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on Ed From abokovoy at redhat.com Tue Nov 4 15:38:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Nov 2014 17:38:34 +0200 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <18057653.145376.1415113130392.JavaMail.root@naumenko.ca> References: <6912624.145341.1415112964441.JavaMail.root@naumenko.ca> <18057653.145376.1415113130392.JavaMail.root@naumenko.ca> Message-ID: <20141104153834.GU4107@redhat.com> On Tue, 04 Nov 2014, Roman Naumenko wrote: >Hi, > > >I'm planning to use FreeIPA to manage infrastructure resources, sudo >users, DNS and things like that. But I also need isp style directory >with multiple organizations and root DNs to control users, mainly for >authentication purpose. FreeIPA wouldn't suitable for latter, so I'm >looking at OpenDJ or Centos DS for that. > > >Could you advise what would be the most suitable product in this case? >And what the difference between RedHat and Centos versions of directory >servers? I'm not entirely understanding what do you mean by 'Centos DS' here but let me guess. FreeIPA uses 389-ds as its LDAP server. It is the same code in both RHEL and CentOS (and other RHEL rebuilds of the same version); there should be no difference at all on source level. FreeIPA, however, adds a number of own plugins to the directory instance that is used for FreeIPA purposes. These plugins are not supported outside of FreeIPA deployment and they implement features we consider important for FreeIPA like user lockout, password changes, Kerberos keys integration, 2FA implementation, DNSSEC integration, etc. You definitely can set up separate instances of 389-ds. Preferably this should be done on separate hosts than IPA masters because otherwise you'll have a number of practical issues with different instances binding to the same LDAP/LDAPS ports and so on. -- / Alexander Bokovoy From matt at indigo.nu Tue Nov 4 15:57:58 2014 From: matt at indigo.nu (Matthew Sellers) Date: Tue, 4 Nov 2014 09:57:58 -0600 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: <5406C25B.1000003@redhat.com> References: <5404092F.2090604@redhat.com> <540444FA.5090800@redhat.com> <54044785.4010302@redhat.com> <5406C25B.1000003@redhat.com> Message-ID: Hi Guys, Thanks for the previous replies. I hate to dig up and old thread, but im still banging my head on this. I am trying to configure IPA to send notify to slaves servers on manual updates from the web or CLI tools. Dynamic DNS updates from an IPA client issuing an nsupdate works great, I get an immediate zone transfer to zone NS slaves ( bind 9.x slaves). Performing an update via IPA CLI ( for non-dynamic static record) tools triggers nothing. The test documents and Petr's previous statements hold true for the nsupdate case, is this also true for CLI driven updates as well? I have tested this on 3.3.5 (Fedora 20) and 4.1 (COPR) release. Thanks Guys! On Wed, Sep 3, 2014 at 2:25 AM, Petr Spacek wrote: > On 1.9.2014 12:16, Dmitri Pal wrote: > >> On 09/01/2014 12:05 PM, Martin Kosek wrote: >> >>> On 09/01/2014 07:50 AM, Dmitri Pal wrote: >>> >>>> On 08/29/2014 09:32 PM, Matthew Sellers wrote: >>>> >>>>> Hi Everyone! >>>>> >>>>> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure >>>>> FreeIPA to >>>>> send notifies to non-IPA slaves, but it seems broken on IPA ( notify >>>>> packets >>>>> are never sent to to slaves ). >>>>> >>>>> I have configured also-notify { nameserverip; }; in named.conf on my >>>>> FreeIPA >>>>> test host in the options section and watched for notify traffic with >>>>> tcpdump. >>>>> >>>>> This document suggests that this is supported, and this is something I >>>>> have >>>>> used in non-IPA bind servers with no issues. >>>>> >>>>> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer >>>>> >>>>> I wanted to ask the list before I file a bug with more details. Is >>>>> anyone >>>>> using this bind feature on IPA with any success? >>>>> >>>>> Thanks! >>>>> Matt >>>>> >>>>> >>>>> The DNS level change propagation is not supported between IPA >>>> replicas instead >>>> it uses LDAP replication to propagate the changes. >>>> If you want another non IPA DNS server to be a slave then you can do >>>> it. See >>>> http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for >>>> more >>>> information. >>>> >>> I thought that from F20, bind-dyndb-ldap was capable of native DNS >>> operations >>> like AXFR/IXFR which can be used to actually deploy slave DNS servers. I >>> wonder >>> if also-notify is something different. CCing Petr Spacek to advise. >>> >> AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves - >> no. >> > > Let me summarize: > - AXFR is supported (at least) by all versions RHEL 6.5 and newer versions > - IXFR is supported by bind-dyndb-ldap 4.0 and newer (Fedora 20+) > - DNS NOTIFY messages are always sent to servers listed in NS records > > I.e. you have to add your non-IPA slave servers to NS records in > particular zone and then it should 'just work', no other configuration > (like 'also-notify') is necessary. > > Please let me know if it doesn't work for you. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 4 16:11:00 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 17:11:00 +0100 Subject: [Freeipa-users] Sync from AD towards FreeIPA directory server In-Reply-To: <5458EE33.3010604@lms.polytechnique.fr> References: <5458EE33.3010604@lms.polytechnique.fr> Message-ID: <5458FA94.1090405@redhat.com> On 11/04/2014 04:18 PM, Edouard Guign? wrote: > Hello FreeIPA Users, > > I am trying to make working a sync between my AD win 2008 R2 and > FreeIPA (fedora 20) server. > My goal is to retrieve all my AD users in freeIPA database. > > 1. With "ipa-replica-manage connect --winsync ...", I succeeded to > copy users from AD to FreeIPA (via the sync agreement) > But passwords have not been sync. I had to reinit password in IPA to > enable user login in the freeipa domain. > Is it a normal issue ? Is there any way to sync password ? I think this is a normal issue when using the PassSync.msi on AD and winsync (as opposed to trusts or another mechanism). > > 2. I tried then to sync posix attributes (from my AD which has > "Subsystem for UNIX-based Applications") into the freeIPA server with > activating the posix winsync plugin > I would like to extract attributes from my AD like : > - uidNumber > - gidNumber > - unixHomeDirectory > - loginShell > - msSFU30NisDomain > > With posix winsync activated, the sync do not work at all... no AD > users sync. > What is missing to enable it ? I follow the documentation here > http://www.port389.org/docs/389ds/design/winsync-posix.html > > And enable the plugin this way : > ldapmodify -D "cn=directory manager" -w xxxxx > dn: cn=Posix Winsync API,cn=plugins,cn=config > changetype: modify > replace: nsslapd-pluginEnabled > nsslapd-pluginEnabled: on Hmm - it should work. What version of 389 are you using? rpm -q 389-ds-base I suggest trying it again and turning on the replication logging level - http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting - and see if there are any clues in the errors log. > > Ed > > From roman at naumenko.ca Tue Nov 4 16:14:29 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 4 Nov 2014 11:14:29 -0500 (EST) Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <20141104153834.GU4107@redhat.com> Message-ID: <29370255.146086.1415117669500.JavaMail.root@naumenko.ca> ----- Original Message ----- > On Tue, 04 Nov 2014, Roman Naumenko wrote: > >Hi, > > > > > >I'm planning to use FreeIPA to manage infrastructure resources, sudo > >users, DNS and things like that. But I also need isp style > >directory > >with multiple organizations and root DNs to control users, mainly > >for > >authentication purpose. FreeIPA wouldn't suitable for latter, so I'm > >looking at OpenDJ or Centos DS for that. > > > > > >Could you advise what would be the most suitable product in this > >case? > >And what the difference between RedHat and Centos versions of > >directory > >servers? > I'm not entirely understanding what do you mean by 'Centos DS' here > but > let me guess. Centos directory server. > FreeIPA uses 389-ds as its LDAP server. It is the same code in both > RHEL > and CentOS (and other RHEL rebuilds of the same version); there > should > be no difference at all on source level. > > FreeIPA, however, adds a number of own plugins to the directory > instance > that is used for FreeIPA purposes. These plugins are not supported > outside of FreeIPA deployment and they implement features we consider > important for FreeIPA like user lockout, password changes, Kerberos > keys > integration, 2FA implementation, DNSSEC integration, etc. All good staff! > You definitely can set up separate instances of 389-ds. Preferably > this > should be done on separate hosts than IPA masters because otherwise > you'll have a number of practical issues with different instances > binding to the same LDAP/LDAPS ports and so on. Is 389-ds equivalent of RedHat Directory Server (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? --Roman From rob.verduijn at gmail.com Tue Nov 4 16:15:52 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 4 Nov 2014 17:15:52 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <5458E83B.8040601@redhat.com> References: <544D5BB2.5090003@redhat.com> <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> Message-ID: The problem with 'foreman-prepare-realm' and freeipa was that it claimed that a few o thef permissions required did not exist when it tried to add them to the 'smart proxy host management' privilege. I think it was because the permissions were all in lower case without the 'System: ' prefix. This is just an assumption since I did not get to work even after adding them manually. So I figured to try it again after reverting back to 3.3.5. After downgrading I learned that it did not work due to a bug in a ruby script. (fixed by commenting out line 505-506 in /usr/share/ruby/xmlrpc/client.rb on the katello host, see https://bugs.ruby-lang.org/issues/8182 and https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) After which I tried the upgrade again. regarding https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart I did look again using the kredentials as mentioned in step 4. and saw only 3 objects (1x idnsConfigObject 2x nsContainer) When using admin credentials I saw all the dns zone entries. I can see the zone entries in the ipa gui. Also when I look at the permissions in ipa there are no longer any permissions that have the 'System: ' prefix. Rob 2014-11-04 15:52 GMT+01:00 Petr Spacek : > On 4.11.2014 15:27, Rob Verduijn wrote: > >> Hello again, >> >> I've managed to integrate my katello configuration with freeipa. >> Now I not only use freeipa authentication in katello but also when a host >> is defined in katello it automagically gets created in the freeipa realm , >> certs, otp,dns all working great. >> >> however, to obtain all this integration greatness I had to downgrade my >> freeipa to 3.3.5 again (revert snapshot) because the katello realm >> integration tool (foreman-prepare-realm) is not capable of dealing with >> 4.X >> versions of freeipa. >> > It would be nice if you could get tell us more details about the problem > you had with Katello, AFAIK we are not aware of any. > > And now the named-pkcs11 again does not see my internal zones. >> >> This page >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >> thinks >> I should contact the freeipa-users list >> > > Do I understand correctly that you did all the steps 0-4 successfully and > then you found out that you can't see DNS objects in LDAP (step 5) when > using ldapsearch with DNS principal? > > Can you see the objects in IPA web UI or CLI? If it is the case then we > will need help from LDAP ACI expert (pviktori? :-). > > Petr^2 Spacek > > > The command 'ipa-ldap-updater >> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >> and the command 'ipa-ldap-updater' didn't fix it either. >> >> So I am now stuck at freeipa 3.3.5 again (with a working katello >> integration, so I got some mixed emotions about it) >> Any ideas anyone ? >> Rob >> >> >> >> >> >> >> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >> >> Hello, >>> >>> I've tested the update again. >>> >>> The bind-utils conflict is still there when I issue "yum update >>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>> http://www.freeipa.org/page/Downloads#Upgrading ) >>> >>> 'yum update' works fine >>> >>> My internal zones didn't resolv after the update >>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't >>> fix >>> it >>> ipa-ldap-updater did fix the 'access control instructions' and my >>> internal >>> dns zones started to resolv again :-) >>> >>> Cheers >>> Rob >>> >>> >>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>> >>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>> >>>> Hello, >>>>> >>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>> fixes the problem. >>>>> >>>>> I can resolv my internal dns zones again:-) >>>>> >>>>> Many thanx. >>>>> >>>>> Since this problem happened every time I tried to update the freeipa >>>>> server. >>>>> I could re-run the update with some debug options if you like so you >>>>> can >>>>> pinpoint what goes wrong with the update script if you like. >>>>> >>>>> >>>> I have re-build some packages in mkosek's CORP so now you should not see >>>> encounter dependency problems. Simple 'yum upgrade' should give you all >>>> the >>>> required packages. >>>> >>>> We are looking at other problems in upgrade process right now so there >>>> is >>>> not much to test except package dependencies. >>>> >>>> -- >>>> Petr^2 Spacek >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 4 16:21:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Nov 2014 18:21:53 +0200 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <29370255.146086.1415117669500.JavaMail.root@naumenko.ca> References: <20141104153834.GU4107@redhat.com> <29370255.146086.1415117669500.JavaMail.root@naumenko.ca> Message-ID: <20141104162153.GW4107@redhat.com> On Tue, 04 Nov 2014, Roman Naumenko wrote: >> You definitely can set up separate instances of 389-ds. Preferably >> this should be done on separate hosts than IPA masters because >> otherwise you'll have a number of practical issues with different >> instances binding to the same LDAP/LDAPS ports and so on. > >Is 389-ds equivalent of RedHat Directory Server >(http://www.redhat.com/en/technologies/cloud-computing/directory-server)? Red Hat Directory Server is what is known as 389 Directory Server (389-ds) upstream project. Essentially, it is the same code. If you have specific questions about support of Red Hat Directory Server, I'd suggest you to ask them Red Hat sales/support people (of which I'm neither one). ;) -- / Alexander Bokovoy From roman at naumenko.ca Tue Nov 4 16:25:39 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 4 Nov 2014 11:25:39 -0500 (EST) Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <20141104162153.GW4107@redhat.com> Message-ID: <18004446.146223.1415118339373.JavaMail.root@naumenko.ca> ----- Original Message ----- > On Tue, 04 Nov 2014, Roman Naumenko wrote: > >> You definitely can set up separate instances of 389-ds. Preferably > >> this should be done on separate hosts than IPA masters because > >> otherwise you'll have a number of practical issues with different > >> instances binding to the same LDAP/LDAPS ports and so on. > > > >Is 389-ds equivalent of RedHat Directory Server > >(http://www.redhat.com/en/technologies/cloud-computing/directory-server)? > Red Hat Directory Server is what is known as 389 Directory Server > (389-ds) upstream project. Essentially, it is the same code. If you > have > specific questions about support of Red Hat Directory Server, I'd > suggest you to ask them Red Hat sales/support people (of which I'm > neither one). ;) Not necessarily sales people have to be involved, Centos has the same project :) I'm pondering what's the difference between Centos and Red Hat versions. --Roman From rmeggins at redhat.com Tue Nov 4 16:28:24 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 17:28:24 +0100 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <20141104162153.GW4107@redhat.com> References: <20141104153834.GU4107@redhat.com> <29370255.146086.1415117669500.JavaMail.root@naumenko.ca> <20141104162153.GW4107@redhat.com> Message-ID: <5458FEA8.5010902@redhat.com> On 11/04/2014 05:21 PM, Alexander Bokovoy wrote: > On Tue, 04 Nov 2014, Roman Naumenko wrote: >>> You definitely can set up separate instances of 389-ds. Preferably >>> this should be done on separate hosts than IPA masters because >>> otherwise you'll have a number of practical issues with different >>> instances binding to the same LDAP/LDAPS ports and so on. >> >> Is 389-ds equivalent of RedHat Directory Server >> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >> > Red Hat Directory Server is what is known as 389 Directory Server > (389-ds) upstream project. Essentially, it is the same code. If you have > specific questions about support of Red Hat Directory Server, I'd > suggest you to ask them Red Hat sales/support people (of which I'm > neither one). ;) > The relationship between 389 and Red Hat Directory Server (RHDS) is roughly the same as the difference between Fedora and Red Hat. 389 is the upstream - it moves fast, goes through versions very quickly, and contains a lot of "bleeding edge" code. RHDS is the downstream - the rate of changes is slower, versions change slowly, and contains very stable code. Periodically, RHDS will rebase to some version of 389. For example, RHEL 6.4 rebased on 389 1.2.1.15. From that point on (RHEL 6.5, RHEL 6.6) we only backport key features and bug fixes, preferably after they have been well tested and QA'd. RHEL 7.1 will rebase RHDS to some version of 1.3.x branch from 389. From dpal at redhat.com Tue Nov 4 16:28:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Nov 2014 11:28:34 -0500 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <18004446.146223.1415118339373.JavaMail.root@naumenko.ca> References: <18004446.146223.1415118339373.JavaMail.root@naumenko.ca> Message-ID: <5458FEB2.7020406@redhat.com> On 11/04/2014 11:25 AM, Roman Naumenko wrote: > ----- Original Message ----- >> On Tue, 04 Nov 2014, Roman Naumenko wrote: >>>> You definitely can set up separate instances of 389-ds. Preferably >>>> this should be done on separate hosts than IPA masters because >>>> otherwise you'll have a number of practical issues with different >>>> instances binding to the same LDAP/LDAPS ports and so on. >>> Is 389-ds equivalent of RedHat Directory Server >>> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >> Red Hat Directory Server is what is known as 389 Directory Server >> (389-ds) upstream project. Essentially, it is the same code. If you >> have >> specific questions about support of Red Hat Directory Server, I'd >> suggest you to ask them Red Hat sales/support people (of which I'm >> neither one). ;) > Not necessarily sales people have to be involved, Centos has the same project :) > I'm pondering what's the difference between Centos and Red Hat versions. RHDS is the layered product. It has 389DS package but also some other tools and utilities that are not a part of core RHEL and thus not in CentOS. It is usable but would be harder to manage without additional tools. > > --Roman > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Tue Nov 4 16:31:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Nov 2014 18:31:18 +0200 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <5458FEB2.7020406@redhat.com> References: <18004446.146223.1415118339373.JavaMail.root@naumenko.ca> <5458FEB2.7020406@redhat.com> Message-ID: <20141104163118.GX4107@redhat.com> On Tue, 04 Nov 2014, Dmitri Pal wrote: >On 11/04/2014 11:25 AM, Roman Naumenko wrote: >>----- Original Message ----- >>>On Tue, 04 Nov 2014, Roman Naumenko wrote: >>>>>You definitely can set up separate instances of 389-ds. Preferably >>>>>this should be done on separate hosts than IPA masters because >>>>>otherwise you'll have a number of practical issues with different >>>>>instances binding to the same LDAP/LDAPS ports and so on. >>>>Is 389-ds equivalent of RedHat Directory Server >>>>(http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >>>Red Hat Directory Server is what is known as 389 Directory Server >>>(389-ds) upstream project. Essentially, it is the same code. If you >>>have >>>specific questions about support of Red Hat Directory Server, I'd >>>suggest you to ask them Red Hat sales/support people (of which I'm >>>neither one). ;) >>Not necessarily sales people have to be involved, Centos has the same project :) >>I'm pondering what's the difference between Centos and Red Hat versions. > >RHDS is the layered product. >It has 389DS package but also some other tools and utilities that are >not a part of core RHEL and thus not in CentOS. >It is usable but would be harder to manage without additional tools. And to add to that, CentOS only has what is in the core RHEL: https://git.centos.org/log/rpms!389-ds-base/refs!heads!c7 -- / Alexander Bokovoy From rmeggins at redhat.com Tue Nov 4 16:32:20 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 17:32:20 +0100 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <5458FEB2.7020406@redhat.com> References: <18004446.146223.1415118339373.JavaMail.root@naumenko.ca> <5458FEB2.7020406@redhat.com> Message-ID: <5458FF94.7000606@redhat.com> On 11/04/2014 05:28 PM, Dmitri Pal wrote: > On 11/04/2014 11:25 AM, Roman Naumenko wrote: >> ----- Original Message ----- >>> On Tue, 04 Nov 2014, Roman Naumenko wrote: >>>>> You definitely can set up separate instances of 389-ds. Preferably >>>>> this should be done on separate hosts than IPA masters because >>>>> otherwise you'll have a number of practical issues with different >>>>> instances binding to the same LDAP/LDAPS ports and so on. >>>> Is 389-ds equivalent of RedHat Directory Server >>>> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >>>> >>> Red Hat Directory Server is what is known as 389 Directory Server >>> (389-ds) upstream project. Essentially, it is the same code. If you >>> have >>> specific questions about support of Red Hat Directory Server, I'd >>> suggest you to ask them Red Hat sales/support people (of which I'm >>> neither one). ;) >> Not necessarily sales people have to be involved, Centos has the same >> project :) >> I'm pondering what's the difference between Centos and Red Hat versions. > > RHDS is the layered product. > It has 389DS package but also some other tools and utilities that are > not a part of core RHEL and thus not in CentOS. However, they are in EPEL - 389-console, 389-admin, etc. > It is usable but would be harder to manage without additional tools. > >> >> --Roman >> > > From simo at redhat.com Tue Nov 4 17:09:04 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 4 Nov 2014 12:09:04 -0500 Subject: [Freeipa-users] Helping testing FreeIPA 4.1.0 on Fedora Server Test Day Message-ID: <20141104120904.7a8c3470@willson.usersys.redhat.com> Hello FreeIPA users, for those that like leaving on the bleeding edge and using the latest bits, we are going to have a Fedora Server Test Day next Friday[1]. One of the features of Fedora Server will be the new rolekit infrastructure, that simplify installing "roles" on the server. One of the main roles that will be introduced with F21 will be the Domain Controller role, based on FreeIPA. It would be really useful if enthusiast users could help with testing FreeIPA 4.1.0 so that we can make sure there aren't any huge outstanding bugs before F21 gets released, and as a perk you also get to enjoy trying the latest FreeIPA release with help from other users and developers if needed. If you can dedicate some time on Friday it would be really welcome, you do not have to complete all tests, you can concentrate on a subset of your choosing too. Any result and validation will be useful. Hope to see some of you online on Friday. See the link below for more information on prerequisites and the list of tests we planned. Cheers, Simo. [1] https://fedoraproject.org/wiki/Test_Day:2014-11-07_Server -- Simo Sorce * Red Hat, Inc * New York From roman at naumenko.ca Tue Nov 4 17:13:00 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 4 Nov 2014 12:13:00 -0500 (EST) Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <5458FF94.7000606@redhat.com> Message-ID: <5771762.146701.1415121180100.JavaMail.root@naumenko.ca> ----- Original Message ----- > On 11/04/2014 05:28 PM, Dmitri Pal wrote: > > On 11/04/2014 11:25 AM, Roman Naumenko wrote: > >> ----- Original Message ----- > >>> On Tue, 04 Nov 2014, Roman Naumenko wrote: > >>>>> You definitely can set up separate instances of 389-ds. > >>>>> Preferably > >>>>> this should be done on separate hosts than IPA masters because > >>>>> otherwise you'll have a number of practical issues with > >>>>> different > >>>>> instances binding to the same LDAP/LDAPS ports and so on. > >>>> Is 389-ds equivalent of RedHat Directory Server > >>>> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? > >>>> > >>> Red Hat Directory Server is what is known as 389 Directory Server > >>> (389-ds) upstream project. Essentially, it is the same code. If > >>> you > >>> have > >>> specific questions about support of Red Hat Directory Server, I'd > >>> suggest you to ask them Red Hat sales/support people (of which > >>> I'm > >>> neither one). ;) > >> Not necessarily sales people have to be involved, Centos has the > >> same > >> project :) > >> I'm pondering what's the difference between Centos and Red Hat > >> versions. > > > > RHDS is the layered product. > > It has 389DS package but also some other tools and utilities that > > are > > not a part of core RHEL and thus not in CentOS. > > However, they are in EPEL - 389-console, 389-admin, etc. You lost me :) Am I understand correctly that everything is equal between centos and redhat directory servers, but redhat will have more stable code? --Roman From rmeggins at redhat.com Tue Nov 4 17:15:33 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 18:15:33 +0100 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <5771762.146701.1415121180100.JavaMail.root@naumenko.ca> References: <5771762.146701.1415121180100.JavaMail.root@naumenko.ca> Message-ID: <545909B5.7060702@redhat.com> On 11/04/2014 06:13 PM, Roman Naumenko wrote: > ----- Original Message ----- >> On 11/04/2014 05:28 PM, Dmitri Pal wrote: >>> On 11/04/2014 11:25 AM, Roman Naumenko wrote: >>>> ----- Original Message ----- >>>>> On Tue, 04 Nov 2014, Roman Naumenko wrote: >>>>>>> You definitely can set up separate instances of 389-ds. >>>>>>> Preferably >>>>>>> this should be done on separate hosts than IPA masters because >>>>>>> otherwise you'll have a number of practical issues with >>>>>>> different >>>>>>> instances binding to the same LDAP/LDAPS ports and so on. >>>>>> Is 389-ds equivalent of RedHat Directory Server >>>>>> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >>>>>> >>>>> Red Hat Directory Server is what is known as 389 Directory Server >>>>> (389-ds) upstream project. Essentially, it is the same code. If >>>>> you >>>>> have >>>>> specific questions about support of Red Hat Directory Server, I'd >>>>> suggest you to ask them Red Hat sales/support people (of which >>>>> I'm >>>>> neither one). ;) >>>> Not necessarily sales people have to be involved, Centos has the >>>> same >>>> project :) >>>> I'm pondering what's the difference between Centos and Red Hat >>>> versions. >>> RHDS is the layered product. >>> It has 389DS package but also some other tools and utilities that >>> are >>> not a part of core RHEL and thus not in CentOS. >> However, they are in EPEL - 389-console, 389-admin, etc. > You lost me :) > Am I understand correctly that everything is equal between centos and redhat directory servers, but redhat will have more stable code? No, sorry. I was talking about 389 upstream vs. RHDS. As CentOS is just a repackager/rebuilder of RHEL packages, there is no difference between CentOS (CentOS DS) and RHEL (RHDS) once CentOS rebuilds. > > --Roman > From dpal at redhat.com Tue Nov 4 18:21:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Nov 2014 13:21:32 -0500 Subject: [Freeipa-users] FreeIPA, RedHat Directory Server and Centros DS In-Reply-To: <545909B5.7060702@redhat.com> References: <5771762.146701.1415121180100.JavaMail.root@naumenko.ca> <545909B5.7060702@redhat.com> Message-ID: <5459192C.5000706@redhat.com> On 11/04/2014 12:15 PM, Rich Megginson wrote: > On 11/04/2014 06:13 PM, Roman Naumenko wrote: >> ----- Original Message ----- >>> On 11/04/2014 05:28 PM, Dmitri Pal wrote: >>>> On 11/04/2014 11:25 AM, Roman Naumenko wrote: >>>>> ----- Original Message ----- >>>>>> On Tue, 04 Nov 2014, Roman Naumenko wrote: >>>>>>>> You definitely can set up separate instances of 389-ds. >>>>>>>> Preferably >>>>>>>> this should be done on separate hosts than IPA masters because >>>>>>>> otherwise you'll have a number of practical issues with >>>>>>>> different >>>>>>>> instances binding to the same LDAP/LDAPS ports and so on. >>>>>>> Is 389-ds equivalent of RedHat Directory Server >>>>>>> (http://www.redhat.com/en/technologies/cloud-computing/directory-server)? >>>>>>> >>>>>>> >>>>>> Red Hat Directory Server is what is known as 389 Directory Server >>>>>> (389-ds) upstream project. Essentially, it is the same code. If >>>>>> you >>>>>> have >>>>>> specific questions about support of Red Hat Directory Server, I'd >>>>>> suggest you to ask them Red Hat sales/support people (of which >>>>>> I'm >>>>>> neither one). ;) >>>>> Not necessarily sales people have to be involved, Centos has the >>>>> same >>>>> project :) >>>>> I'm pondering what's the difference between Centos and Red Hat >>>>> versions. >>>> RHDS is the layered product. >>>> It has 389DS package but also some other tools and utilities that >>>> are >>>> not a part of core RHEL and thus not in CentOS. >>> However, they are in EPEL - 389-console, 389-admin, etc. >> You lost me :) >> Am I understand correctly that everything is equal between centos and >> redhat directory servers, but redhat will have more stable code? > > No, sorry. I was talking about 389 upstream vs. RHDS. > > As CentOS is just a repackager/rebuilder of RHEL packages, there is no > difference between CentOS (CentOS DS) and RHEL (RHDS) once CentOS > rebuilds. > >> >> --Roman >> > Core RHEL and thus CentOS do not have all the packages that constitute RHDS as a product. Does that make sense? Fedora has everything. Upstream too. But extra packages are delivered on RHEL on top of the platform not as mut of it and thus they are not built for CentOS. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Nov 4 18:27:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Nov 2014 13:27:53 -0500 Subject: [Freeipa-users] Question about oVirt Message-ID: <54591AA9.9000906@redhat.com> Hello Jim, I am re-posting your question to the FreeIPA list as it belongs there. Here is the copy of the original question. Subject: [ovirt-users] templates and freeipa From: Jim Kinney Date: 10/31/2014 02:55 PM To: "users at ovirt.org" Ovirt 3.5 is running well for me and I have freeIPA controlling access to the user portal. I would like to provide templates of various linux setups that all have freeipa for user authentication in the VM for my developers to be able to create a new VM from and then log in using their freeIPA access and sudo control. I'm wanting to group developers by project and use freeIPA to set sudo commands as needed (group A get oracle, group B get postgresql, etc). Wanting to maximize developer ability while minimizing my clean up time :-) They will be able to delete VMs they create. It's possible to do a kickstart deploy with freeIPA registration but a template from that will be a problem as it will have the same keys for all VMs. Is there a post-creation scripting process I can attach to in ovirt or should I look at a default root user and script that personalizes the new VM? -- -- James P. Kinney III //// ////Every time you stop a school, you will have to build a jail. What you gain at one end you lose at the other. It's like feeding a dog on his own tail. It won't fatten the dog. - Speech 11/23/1900 Mark Twain //// http://heretothereideas.blogspot.com/ //// -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at familjenklar.se Tue Nov 4 18:50:13 2014 From: richard at familjenklar.se (richard) Date: Tue, 04 Nov 2014 19:50:13 +0100 Subject: [Freeipa-users] vcenter 5.5 and freeipa 3 authentication Message-ID: <91ade6f1b7c5a0997ef5542cca9fdbd5@familjenklar.se> We are trying to configure vcenter 5.5 to authenticate against freeipa instead of AD. Its working for single users, we can update passwd in freeipa and they can authenticate aganinst vcenter. But we are not able to get the groups to work as we want, we cant even see them on the vcenter side. Has any one configured vcenter to authenticate against freeipa, with booth users and groups working? // Richard From rcritten at redhat.com Tue Nov 4 20:02:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Nov 2014 15:02:52 -0500 Subject: [Freeipa-users] vcenter 5.5 and freeipa 3 authentication In-Reply-To: <91ade6f1b7c5a0997ef5542cca9fdbd5@familjenklar.se> References: <91ade6f1b7c5a0997ef5542cca9fdbd5@familjenklar.se> Message-ID: <545930EC.6070907@redhat.com> richard wrote: > We are trying to configure vcenter 5.5 to authenticate against freeipa > instead of AD. > Its working for single users, we can update passwd in freeipa and they > can authenticate aganinst vcenter. > But we are not able to get the groups to work as we want, we cant even > see them on the vcenter side. > > > Has any one configured vcenter to authenticate against freeipa, with > booth users and groups working? > > // Richard > How are you configuring it, using the Open LDAP option? According to http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2064977 the group scheme used by IPA is not supported. They require the objectclass groupOfUniqueNames and uniqueMember. It should be possible to add configuration to IPA to enable this via the slapi-nis (schema compat) plugin. See this, https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/sch-getting-started.txt rob From dpal at redhat.com Tue Nov 4 20:16:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Nov 2014 15:16:10 -0500 Subject: [Freeipa-users] Question about oVirt In-Reply-To: <54591AA9.9000906@redhat.com> References: <54591AA9.9000906@redhat.com> Message-ID: <5459340A.8000704@redhat.com> On 11/04/2014 01:27 PM, Dmitri Pal wrote: > Hello Jim, > > I am re-posting your question to the FreeIPA list as it belongs there. > > Here is the copy of the original question. > > Subject: > [ovirt-users] templates and freeipa > From: > Jim Kinney > Date: > 10/31/2014 02:55 PM > > To: > "users at ovirt.org" > > > Ovirt 3.5 is running well for me and I have freeIPA controlling access > to the user portal. I would like to provide templates of various linux > setups that all have freeipa for user authentication in the VM for my > developers to be able to create a new VM from and then log in using > their freeIPA access and sudo control. I'm wanting to group developers > by project and use freeIPA to set sudo commands as needed (group A get > oracle, group B get postgresql, etc). Wanting to maximize developer > ability while minimizing my clean up time :-) They will be able to > delete VMs they create. > > It's possible to do a kickstart deploy with freeIPA registration but a > template from that will be a problem as it will have the same keys for > all VMs. > > Is there a post-creation scripting process I can attach to in ovirt or > should I look at a default root user and script that personalizes the > new VM? > > -- > -- > James P. Kinney III > //// > ////Every time you stop a school, you will have to build a jail. What > you gain at one end you lose at the other. It's like feeding a dog on > his own tail. It won't fatten the dog. > - Speech 11/23/1900 Mark Twain > //// > http://heretothereideas.blogspot.com/ > //// > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Which provisioning technique you are using? Would something like what Adam describes here [1] or Foreman uses here [2] would be relevant? [1] http://adam.younglogic.com/2013/09/register-vm-freeipa/ [2] http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at familjenklar.se Tue Nov 4 20:51:41 2014 From: richard at familjenklar.se (richard) Date: Tue, 04 Nov 2014 21:51:41 +0100 Subject: [Freeipa-users] vcenter 5.5 and freeipa 3 authentication In-Reply-To: <545930EC.6070907@redhat.com> References: <91ade6f1b7c5a0997ef5542cca9fdbd5@familjenklar.se> <545930EC.6070907@redhat.com> Message-ID: <85ff481f9c56e4c0d881a7ebf64b14d3@familjenklar.se> 2014-11-04 21:02 skrev Rob Crittenden: > richard wrote: >> We are trying to configure vcenter 5.5 to authenticate against freeipa >> instead of AD. >> Its working for single users, we can update passwd in freeipa and they >> can authenticate aganinst vcenter. >> But we are not able to get the groups to work as we want, we cant even >> see them on the vcenter side. >> >> >> Has any one configured vcenter to authenticate against freeipa, with >> booth users and groups working? >> >> // Richard >> > > How are you configuring it, using the Open LDAP option? > > According to > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2064977 > the group scheme used by IPA is not supported. They require the > objectclass groupOfUniqueNames and uniqueMember. > > It should be possible to add configuration to IPA to enable this via > the > slapi-nis (schema compat) plugin. See this, > https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/sch-getting-started.txt > > rob Im configuring it with the OpenLdap option. I will check the slapi-nis plugin, and see if i can get it to work. Thanks for the tip. // Richard From william.muriithi at gmail.com Tue Nov 4 20:57:17 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 04 Nov 2014 15:57:17 -0500 Subject: [Freeipa-users] Trust relationship redundancy Message-ID: <20141104205717.6090901.65033.7509@gmail.com> An HTML attachment was scrubbed... URL: From david.taylor at speedcast.com Wed Nov 5 02:30:55 2014 From: david.taylor at speedcast.com (David Taylor) Date: Wed, 5 Nov 2014 02:30:55 +0000 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> Message-ID: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> Thanks for the reply. The PAM file is pretty stock for a centos build #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Best regards David Taylor -----Original Message----- From: Jakub Hrozek [mailto:jhrozek at redhat.com] Sent: Friday, 31 October 2014 7:35 PM To: David Taylor Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 > On 31 Oct 2014, at 02:23, David Taylor wrote: > > I just recently updated one of our test servers from CentOS 6.5 to CentOS 6.6, after which I noticed that IPA logons were no longer available. From what I can see the upgrade includes quite a few changes with regard to sssd. > > - NTP is up and synced on the Auth servers and the client. > - DNS is working to the IPA servers > - I can do a kinit for users with no problem > - I have uninstalled the ipa client, deleted the host profile on the IPA server and one a rejoin. The rejoin worked but the problem is the same. > > Software versions using > - rpm -qa | grep -i ipa > - rpm -qa | grep -i sssd > > Software versions before: > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > device-mapper-multipath-0.4.9-72.el6_5.4.x86_64 > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > device-mapper-multipath-libs-0.4.9-72.el6_5.4.x86_64 > sssd-1.9.2-129.el6_5.4.x86_64 > sssd-client-1.9.2-129.el6_5.4.x86_64 > > Software version after: > sssd-ipa-1.11.6-30.el6.x86_64 > libipa_hbac-1.11.6-30.el6.x86_64 > device-mapper-multipath-libs-0.4.9-80.el6.x86_64 > ipa-client-3.0.0-42.el6.centos.x86_64 > libipa_hbac-python-1.11.6-30.el6.x86_64 > ipa-python-3.0.0-42.el6.centos.x86_64 > device-mapper-multipath-0.4.9-80.el6.x86_64 > sssd-ldap-1.11.6-30.el6.x86_64 > sssd-ad-1.11.6-30.el6.x86_64 > python-sssdconfig-1.11.6-30.el6.noarch > sssd-client-1.11.6-30.el6.x86_64 > sssd-krb5-common-1.11.6-30.el6.x86_64 > sssd-ipa-1.11.6-30.el6.x86_64 > sssd-common-1.11.6-30.el6.x86_64 > sssd-proxy-1.11.6-30.el6.x86_64 > sssd-common-pac-1.11.6-30.el6.x86_64 > sssd-krb5-1.11.6-30.el6.x86_64 > sssd-1.11.6-30.el6.x86_64 > The /var/log/secure logs show the following > > Oct 31 10:38:30 test01 sshd[2790]: Invalid user dtaylor from removed> Oct 31 10:38:30 test01 sshd[2791]: input_userauth_request: > invalid user dtaylor Oct 31 10:38:30 test01 sshd[2790]: > pam_unix(sshd:auth): check pass; user unknown Oct 31 10:38:30 test01 > sshd[2790]: pam_unix(sshd:auth): authentication failure; logname= > uid=0 euid=0 tty=ssh ruser= rhost= Oct 31 10:38:30 > test01 sshd[2790]: pam_succeed_if(sshd:auth): error retrieving > information about user dtaylor > Do you also see pam_sss being mentioned at all in your /var/log/secure at all? Can you paste your PAM configuration? It?s expected that pam_unix fails to find the IPA user, but I would also expect the PAM stack to ask pam_sss next... > The /var/log/audit/audit.log logs show the following > > type=CRYPTO_KEY_USER msg=audit(1414715857.270:107): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715857.270:108): user pid=5831 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5831 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1414715857.272:109): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1414715857.272:110): user pid=5830 uid=0 auid=0 ses=1 msg='op=start direction=from-server cipher=aes256-ctr ksize=256 spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=USER_LOGIN msg=audit(1414715857.310:111): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > type=USER_AUTH msg=audit(1414715859.211:112): user pid=5830 uid=0 auid=0 ses=1 msg='op=PAM:authentication acct="?" exe="/usr/sbin/sshd" hostname= addr= terminal=ssh res=failed' > type=USER_AUTH msg=audit(1414715859.212:113): user pid=5830 uid=0 auid=0 ses=1 msg='op=password acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > type=CRYPTO_KEY_USER msg=audit(1414715862.076:114): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=session fp=? direction=both spid=5831 suid=74 rport=44361 laddr= lport=22 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715862.078:115): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1414715862.079:116): user pid=5830 uid=0 auid=0 ses=1 msg='op=destroy kind=server fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5830 suid=0 exe="/usr/sbin/sshd" hostname=? addr= terminal=? res=success' > type=USER_LOGIN msg=audit(1414715862.079:117): user pid=5830 uid=0 auid=0 ses=1 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr= terminal=ssh res=failed' > > The /var/log/sssd/sssd_.log logs show the > following > > ==> /var/log/sssd/sssd_.log <== (Fri Oct 31 > 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] > (0x4000): dbus conn: 0x16699b0 (Fri Oct 31 12:13:39 2014) [sssd[be[]]] [sbus_dispatch] (0x4000): Dispatching. > (Fri Oct 31 12:13:39 2014) [sssd[be[]]] > [sbus_message_handler] (0x4000): Received SBUS method [ping] (Fri Oct > 31 12:13:39 2014) [sssd[be[]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Fri > Oct 31 12:13:39 2014) [sssd[be[]]] > [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] These are just heartbeats between sssd_be and the main sssd process, not a real activity. > -- > 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 From mkosek at redhat.com Wed Nov 5 08:39:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Nov 2014 09:39:19 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> Message-ID: <5459E237.90803@redhat.com> On 11/04/2014 01:39 PM, Natxo Asenjo wrote: > hi, > > On Mon, Nov 3, 2014 at 5:21 PM, Rob Crittenden wrote: >> Natxo Asenjo wrote: > >>> How often does the crl list get generated? i still do not see recent data. >> >> This is controlled by ca.crl.MasterCRL.autoUpdateInterval which by >> default is 240, so every 4 hours. > > mmm, still no new items in the https://kdc01.sub.domain.tld/ipa/crl/ > site. Everything is stuck on june 28 2013. I would check PKI system logs and also look for any AVCs. There were SELinux policy related bugs in the past which prevented creation of the CRLs in /var/lib/ipa/pki-ca/publish/. Martin From jhrozek at redhat.com Wed Nov 5 09:05:07 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 5 Nov 2014 10:05:07 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> Message-ID: <20141105090507.GZ14368@hendrix.brq.redhat.com> On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > Thanks for the reply. The PAM file is pretty stock for a centos build > > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > > Best regards > David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM configuration? From pspacek at redhat.com Wed Nov 5 09:16:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Nov 2014 10:16:06 +0100 Subject: [Freeipa-users] Trust relationship redundancy In-Reply-To: <20141104205717.6090901.65033.7509@gmail.com> References: <20141104205717.6090901.65033.7509@gmail.com> Message-ID: <5459EAD6.8080404@redhat.com> On 4.11.2014 21:57, William Muriithi wrote: > Afternoon, > > I have two AD and would like to retain that redundancy within IPA after > establishing trust relationship. How would one achieve that? > > I have attempted the following: > > > [root at ipa3-yyz-int ~]# ipa dnszone-add example.local > --name-server=srvyyzdc02.example.local --name-server=srvyyzdc01.example.local > --admin-email='systemadmin at example.com' --force --forwarder=10.10.10.90 > --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.90 > --ip-address=10.10.10.91 > ipa: ERROR: invalid 'idnssoamname': Only one value is allowed > > And got the following error above > > This however works > > ipa dnszone-add example.local --name-server=srvyyzdc02.example.local > --admin-email='systemadmin at example.com > ' > --force --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.91 > > What should I have done to get redundancy working? If this is not possible > currently, any chance it can be implemented some day? Hello, Could you explain what you are trying to achieve, please? What version of FreeIPA do you use? Commands 'ipa dnszone-*' manage DNS and are not strictly related to AD trusts. If you add DNS zone to one IPA server it is automatically served by all other servers. This applies to master & forward zones too. To get full redundancy for *master* zones you have to add all names of IPA DNS servers to NS records in the zone and also to its parent zone. (BTW FreeIPA 4.1 will manage in-zone NS records automatically for you.) For forward zones you don't need to do anything else. It should just work. -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 5 13:39:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Nov 2014 14:39:56 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> Message-ID: <545A28AC.6070700@redhat.com> On 4.11.2014 17:15, Rob Verduijn wrote: > The problem with 'foreman-prepare-realm' and freeipa was that it claimed > that a few o thef permissions required did not exist when it tried to add > them to the 'smart proxy host management' privilege. > > I think it was because the permissions were all in lower case without the > 'System: ' prefix. This is just an assumption since I did not get to work > even after adding them manually. So I figured to try it again after > reverting back to 3.3.5. > > After downgrading I learned that it did not work due to a bug in a ruby > script. (fixed by commenting out line 505-506 > in /usr/share/ruby/xmlrpc/client.rb on the katello host, see > https://bugs.ruby-lang.org/issues/8182 and > https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) > > After which I tried the upgrade again. > > regarding > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > I did look again using the kredentials as mentioned in step 4. and saw only > 3 objects (1x idnsConfigObject 2x nsContainer) > When using admin credentials I saw all the dns zone entries. > > I can see the zone entries in the ipa gui. > > Also when I look at the permissions in ipa there are no longer any > permissions that have the 'System: ' prefix. AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x because it was obsoleted by 'native' proxy delivered by Foreman upstream. Am I right, Rob (Crittenden)? :-) Anyway, back to your DNS problem. Did it worked before you installed Foreman proxy? Or not? I.e. is it working when you revert the snapshot? Do you have other replicas in the replication topology? Please keep in mind that changes in LDAP (including changes to permissions) are replicated so reverting one VM and not others is not necessarily enough. Petr^2 Spacek > 2014-11-04 15:52 GMT+01:00 Petr Spacek : > >> On 4.11.2014 15:27, Rob Verduijn wrote: >> >>> Hello again, >>> >>> I've managed to integrate my katello configuration with freeipa. >>> Now I not only use freeipa authentication in katello but also when a host >>> is defined in katello it automagically gets created in the freeipa realm , >>> certs, otp,dns all working great. >>> >>> however, to obtain all this integration greatness I had to downgrade my >>> freeipa to 3.3.5 again (revert snapshot) because the katello realm >>> integration tool (foreman-prepare-realm) is not capable of dealing with >>> 4.X >>> versions of freeipa. >>> >> It would be nice if you could get tell us more details about the problem >> you had with Katello, AFAIK we are not aware of any. >> >> And now the named-pkcs11 again does not see my internal zones. >>> >>> This page >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>> thinks >>> I should contact the freeipa-users list >>> >> >> Do I understand correctly that you did all the steps 0-4 successfully and >> then you found out that you can't see DNS objects in LDAP (step 5) when >> using ldapsearch with DNS principal? >> >> Can you see the objects in IPA web UI or CLI? If it is the case then we >> will need help from LDAP ACI expert (pviktori? :-). >> >> Petr^2 Spacek >> >> >> The command 'ipa-ldap-updater >>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >>> and the command 'ipa-ldap-updater' didn't fix it either. >>> >>> So I am now stuck at freeipa 3.3.5 again (with a working katello >>> integration, so I got some mixed emotions about it) >>> Any ideas anyone ? >>> Rob >>> >>> >>> >>> >>> >>> >>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >>> >>> Hello, >>>> >>>> I've tested the update again. >>>> >>>> The bind-utils conflict is still there when I issue "yum update >>>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>>> http://www.freeipa.org/page/Downloads#Upgrading ) >>>> >>>> 'yum update' works fine >>>> >>>> My internal zones didn't resolv after the update >>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't >>>> fix >>>> it >>>> ipa-ldap-updater did fix the 'access control instructions' and my >>>> internal >>>> dns zones started to resolv again :-) >>>> >>>> Cheers >>>> Rob >>>> >>>> >>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>>> >>>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>> fixes the problem. >>>>>> >>>>>> I can resolv my internal dns zones again:-) >>>>>> >>>>>> Many thanx. >>>>>> >>>>>> Since this problem happened every time I tried to update the freeipa >>>>>> server. >>>>>> I could re-run the update with some debug options if you like so you >>>>>> can >>>>>> pinpoint what goes wrong with the update script if you like. >>>>>> >>>>>> >>>>> I have re-build some packages in mkosek's CORP so now you should not see >>>>> encounter dependency problems. Simple 'yum upgrade' should give you all >>>>> the >>>>> required packages. >>>>> >>>>> We are looking at other problems in upgrade process right now so there >>>>> is >>>>> not much to test except package dependencies. From rcritten at redhat.com Wed Nov 5 14:41:59 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Nov 2014 09:41:59 -0500 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A28AC.6070700@redhat.com> References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> Message-ID: <545A3737.5000108@redhat.com> Petr Spacek wrote: > On 4.11.2014 17:15, Rob Verduijn wrote: >> The problem with 'foreman-prepare-realm' and freeipa was that it claimed >> that a few o thef permissions required did not exist when it tried to add >> them to the 'smart proxy host management' privilege. >> >> I think it was because the permissions were all in lower case without the >> 'System: ' prefix. This is just an assumption since I did not get to work >> even after adding them manually. So I figured to try it again after >> reverting back to 3.3.5. >> >> After downgrading I learned that it did not work due to a bug in a ruby >> script. (fixed by commenting out line 505-506 >> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see >> https://bugs.ruby-lang.org/issues/8182 and >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) >> >> After which I tried the upgrade again. >> >> regarding >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >> I did look again using the kredentials as mentioned in step 4. and saw >> only >> 3 objects (1x idnsConfigObject 2x nsContainer) >> When using admin credentials I saw all the dns zone entries. >> >> I can see the zone entries in the ipa gui. >> >> Also when I look at the permissions in ipa there are no longer any >> permissions that have the 'System: ' prefix. > > AFAIK the foreman proxy is not necessary (and not supported) with IPA > 4.x because it was obsoleted by 'native' proxy delivered by Foreman > upstream. > > Am I right, Rob (Crittenden)? :-) I believe he's referring to the native smart proxy here. It includes a script to setup permissions. I guess it hasn't been tested against a 4.x IPA master. rob > Anyway, back to your DNS problem. Did it worked before you installed > Foreman proxy? Or not? I.e. is it working when you revert the snapshot? > > Do you have other replicas in the replication topology? Please keep in > mind that changes in LDAP (including changes to permissions) are > replicated so reverting one VM and not others is not necessarily enough. > > Petr^2 Spacek > >> 2014-11-04 15:52 GMT+01:00 Petr Spacek : >> >>> On 4.11.2014 15:27, Rob Verduijn wrote: >>> >>>> Hello again, >>>> >>>> I've managed to integrate my katello configuration with freeipa. >>>> Now I not only use freeipa authentication in katello but also when a >>>> host >>>> is defined in katello it automagically gets created in the freeipa >>>> realm , >>>> certs, otp,dns all working great. >>>> >>>> however, to obtain all this integration greatness I had to downgrade my >>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm >>>> integration tool (foreman-prepare-realm) is not capable of dealing with >>>> 4.X >>>> versions of freeipa. >>>> >>> It would be nice if you could get tell us more details about the problem >>> you had with Katello, AFAIK we are not aware of any. >>> >>> And now the named-pkcs11 again does not see my internal zones. >>>> >>>> This page >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>>> thinks >>>> I should contact the freeipa-users list >>>> >>> >>> Do I understand correctly that you did all the steps 0-4 successfully >>> and >>> then you found out that you can't see DNS objects in LDAP (step 5) when >>> using ldapsearch with DNS principal? >>> >>> Can you see the objects in IPA web UI or CLI? If it is the case then we >>> will need help from LDAP ACI expert (pviktori? :-). >>> >>> Petr^2 Spacek >>> >>> >>> The command 'ipa-ldap-updater >>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >>>> and the command 'ipa-ldap-updater' didn't fix it either. >>>> >>>> So I am now stuck at freeipa 3.3.5 again (with a working katello >>>> integration, so I got some mixed emotions about it) >>>> Any ideas anyone ? >>>> Rob >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >>>> >>>> Hello, >>>>> >>>>> I've tested the update again. >>>>> >>>>> The bind-utils conflict is still there when I issue "yum update >>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>>>> http://www.freeipa.org/page/Downloads#Upgrading ) >>>>> >>>>> 'yum update' works fine >>>>> >>>>> My internal zones didn't resolv after the update >>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't >>>>> fix >>>>> it >>>>> ipa-ldap-updater did fix the 'access control instructions' and my >>>>> internal >>>>> dns zones started to resolv again :-) >>>>> >>>>> Cheers >>>>> Rob >>>>> >>>>> >>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>>>> >>>>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>>>> >>>>>> Hello, >>>>>>> >>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>>> fixes the problem. >>>>>>> >>>>>>> I can resolv my internal dns zones again:-) >>>>>>> >>>>>>> Many thanx. >>>>>>> >>>>>>> Since this problem happened every time I tried to update the freeipa >>>>>>> server. >>>>>>> I could re-run the update with some debug options if you like so you >>>>>>> can >>>>>>> pinpoint what goes wrong with the update script if you like. >>>>>>> >>>>>>> >>>>>> I have re-build some packages in mkosek's CORP so now you should >>>>>> not see >>>>>> encounter dependency problems. Simple 'yum upgrade' should give >>>>>> you all >>>>>> the >>>>>> required packages. >>>>>> >>>>>> We are looking at other problems in upgrade process right now so >>>>>> there >>>>>> is >>>>>> not much to test except package dependencies. From rob.verduijn at gmail.com Wed Nov 5 15:09:18 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 5 Nov 2014 16:09:18 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A28AC.6070700@redhat.com> References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> Message-ID: Hello again, I don't know about foreman upstream, the current version that I am using included in the katello installation is 1.6 And the foreman manpage still requires the configuration of the realm-smart-proxy. http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm About the snapshot: I removed all the katello entries from my current freeipa installation ( I peeked in the script to see what it did ) - user (foreman-realm) - role (Smart Host Proxy Manager) - privilege (Smart Host Proxy Management) - 3 custom permissions ( modify host password, write host certificate, modify host userclass ) applied the update to freeipa 4.1. my local dns zones did not resolv again running the ipa-ldap-updater did not fix it So I guess that it is not due to the katello integration or the realm-smart-proxy script. Rob 2014-11-05 14:39 GMT+01:00 Petr Spacek : > On 4.11.2014 17:15, Rob Verduijn wrote: > >> The problem with 'foreman-prepare-realm' and freeipa was that it claimed >> that a few o thef permissions required did not exist when it tried to add >> them to the 'smart proxy host management' privilege. >> >> I think it was because the permissions were all in lower case without the >> 'System: ' prefix. This is just an assumption since I did not get to work >> even after adding them manually. So I figured to try it again after >> reverting back to 3.3.5. >> >> After downgrading I learned that it did not work due to a bug in a ruby >> script. (fixed by commenting out line 505-506 >> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see >> https://bugs.ruby-lang.org/issues/8182 and >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) >> >> After which I tried the upgrade again. >> >> regarding >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >> I did look again using the kredentials as mentioned in step 4. and saw >> only >> 3 objects (1x idnsConfigObject 2x nsContainer) >> When using admin credentials I saw all the dns zone entries. >> >> I can see the zone entries in the ipa gui. >> >> Also when I look at the permissions in ipa there are no longer any >> permissions that have the 'System: ' prefix. >> > > AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x > because it was obsoleted by 'native' proxy delivered by Foreman upstream. > > Am I right, Rob (Crittenden)? :-) > > Anyway, back to your DNS problem. Did it worked before you installed > Foreman proxy? Or not? I.e. is it working when you revert the snapshot? > > Do you have other replicas in the replication topology? Please keep in > mind that changes in LDAP (including changes to permissions) are replicated > so reverting one VM and not others is not necessarily enough. > > Petr^2 Spacek > > > 2014-11-04 15:52 GMT+01:00 Petr Spacek : >> >> On 4.11.2014 15:27, Rob Verduijn wrote: >>> >>> Hello again, >>>> >>>> I've managed to integrate my katello configuration with freeipa. >>>> Now I not only use freeipa authentication in katello but also when a >>>> host >>>> is defined in katello it automagically gets created in the freeipa >>>> realm , >>>> certs, otp,dns all working great. >>>> >>>> however, to obtain all this integration greatness I had to downgrade my >>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm >>>> integration tool (foreman-prepare-realm) is not capable of dealing with >>>> 4.X >>>> versions of freeipa. >>>> >>>> It would be nice if you could get tell us more details about the >>> problem >>> you had with Katello, AFAIK we are not aware of any. >>> >>> And now the named-pkcs11 again does not see my internal zones. >>> >>>> >>>> This page >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>>> thinks >>>> I should contact the freeipa-users list >>>> >>>> >>> Do I understand correctly that you did all the steps 0-4 successfully and >>> then you found out that you can't see DNS objects in LDAP (step 5) when >>> using ldapsearch with DNS principal? >>> >>> Can you see the objects in IPA web UI or CLI? If it is the case then we >>> will need help from LDAP ACI expert (pviktori? :-). >>> >>> Petr^2 Spacek >>> >>> >>> The command 'ipa-ldap-updater >>> >>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >>>> and the command 'ipa-ldap-updater' didn't fix it either. >>>> >>>> So I am now stuck at freeipa 3.3.5 again (with a working katello >>>> integration, so I got some mixed emotions about it) >>>> Any ideas anyone ? >>>> Rob >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >>>> >>>> Hello, >>>> >>>>> >>>>> I've tested the update again. >>>>> >>>>> The bind-utils conflict is still there when I issue "yum update >>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>>>> http://www.freeipa.org/page/Downloads#Upgrading ) >>>>> >>>>> 'yum update' works fine >>>>> >>>>> My internal zones didn't resolv after the update >>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't >>>>> fix >>>>> it >>>>> ipa-ldap-updater did fix the 'access control instructions' and my >>>>> internal >>>>> dns zones started to resolv again :-) >>>>> >>>>> Cheers >>>>> Rob >>>>> >>>>> >>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>>>> >>>>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>>> >>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>>> fixes the problem. >>>>>>> >>>>>>> I can resolv my internal dns zones again:-) >>>>>>> >>>>>>> Many thanx. >>>>>>> >>>>>>> Since this problem happened every time I tried to update the freeipa >>>>>>> server. >>>>>>> I could re-run the update with some debug options if you like so you >>>>>>> can >>>>>>> pinpoint what goes wrong with the update script if you like. >>>>>>> >>>>>>> >>>>>>> I have re-build some packages in mkosek's CORP so now you should >>>>>> not see >>>>>> encounter dependency problems. Simple 'yum upgrade' should give you >>>>>> all >>>>>> the >>>>>> required packages. >>>>>> >>>>>> We are looking at other problems in upgrade process right now so there >>>>>> is >>>>>> not much to test except package dependencies. >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 5 15:11:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Nov 2014 16:11:50 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> Message-ID: <545A3E36.4070709@redhat.com> Hello, Rob V., you did not answered to my question when DNS worked for you last time. Did it work right after reverting the snapshot? Petr^2 Spacek On 5.11.2014 16:09, Rob Verduijn wrote: > Hello again, > > I don't know about foreman upstream, the current version that I am using > included in the katello installation is 1.6 > And the foreman manpage still requires the configuration of the > realm-smart-proxy. > http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm > > About the snapshot: > I removed all the katello entries from my current freeipa installation ( I > peeked in the script to see what it did ) > - user (foreman-realm) > - role (Smart Host Proxy Manager) > - privilege (Smart Host Proxy Management) > - 3 custom permissions ( modify host password, write host certificate, > modify host userclass ) > applied the update to freeipa 4.1. > my local dns zones did not resolv again > running the ipa-ldap-updater did not fix it > > So I guess that it is not due to the katello integration or the > realm-smart-proxy script. > > Rob > > 2014-11-05 14:39 GMT+01:00 Petr Spacek : > >> On 4.11.2014 17:15, Rob Verduijn wrote: >> >>> The problem with 'foreman-prepare-realm' and freeipa was that it claimed >>> that a few o thef permissions required did not exist when it tried to add >>> them to the 'smart proxy host management' privilege. >>> >>> I think it was because the permissions were all in lower case without the >>> 'System: ' prefix. This is just an assumption since I did not get to work >>> even after adding them manually. So I figured to try it again after >>> reverting back to 3.3.5. >>> >>> After downgrading I learned that it did not work due to a bug in a ruby >>> script. (fixed by commenting out line 505-506 >>> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see >>> https://bugs.ruby-lang.org/issues/8182 and >>> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) >>> >>> After which I tried the upgrade again. >>> >>> regarding >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>> I did look again using the kredentials as mentioned in step 4. and saw >>> only >>> 3 objects (1x idnsConfigObject 2x nsContainer) >>> When using admin credentials I saw all the dns zone entries. >>> >>> I can see the zone entries in the ipa gui. >>> >>> Also when I look at the permissions in ipa there are no longer any >>> permissions that have the 'System: ' prefix. >>> >> >> AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x >> because it was obsoleted by 'native' proxy delivered by Foreman upstream. >> >> Am I right, Rob (Crittenden)? :-) >> >> Anyway, back to your DNS problem. Did it worked before you installed >> Foreman proxy? Or not? I.e. is it working when you revert the snapshot? >> >> Do you have other replicas in the replication topology? Please keep in >> mind that changes in LDAP (including changes to permissions) are replicated >> so reverting one VM and not others is not necessarily enough. >> >> Petr^2 Spacek >> >> >> 2014-11-04 15:52 GMT+01:00 Petr Spacek : >>> >>> On 4.11.2014 15:27, Rob Verduijn wrote: >>>> >>>> Hello again, >>>>> >>>>> I've managed to integrate my katello configuration with freeipa. >>>>> Now I not only use freeipa authentication in katello but also when a >>>>> host >>>>> is defined in katello it automagically gets created in the freeipa >>>>> realm , >>>>> certs, otp,dns all working great. >>>>> >>>>> however, to obtain all this integration greatness I had to downgrade my >>>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm >>>>> integration tool (foreman-prepare-realm) is not capable of dealing with >>>>> 4.X >>>>> versions of freeipa. >>>>> >>>>> It would be nice if you could get tell us more details about the >>>> problem >>>> you had with Katello, AFAIK we are not aware of any. >>>> >>>> And now the named-pkcs11 again does not see my internal zones. >>>> >>>>> >>>>> This page >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>>>> thinks >>>>> I should contact the freeipa-users list >>>>> >>>>> >>>> Do I understand correctly that you did all the steps 0-4 successfully and >>>> then you found out that you can't see DNS objects in LDAP (step 5) when >>>> using ldapsearch with DNS principal? >>>> >>>> Can you see the objects in IPA web UI or CLI? If it is the case then we >>>> will need help from LDAP ACI expert (pviktori? :-). >>>> >>>> Petr^2 Spacek >>>> >>>> >>>> The command 'ipa-ldap-updater >>>> >>>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >>>>> and the command 'ipa-ldap-updater' didn't fix it either. >>>>> >>>>> So I am now stuck at freeipa 3.3.5 again (with a working katello >>>>> integration, so I got some mixed emotions about it) >>>>> Any ideas anyone ? >>>>> Rob >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> I've tested the update again. >>>>>> >>>>>> The bind-utils conflict is still there when I issue "yum update >>>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>>>>> http://www.freeipa.org/page/Downloads#Upgrading ) >>>>>> >>>>>> 'yum update' works fine >>>>>> >>>>>> My internal zones didn't resolv after the update >>>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't >>>>>> fix >>>>>> it >>>>>> ipa-ldap-updater did fix the 'access control instructions' and my >>>>>> internal >>>>>> dns zones started to resolv again :-) >>>>>> >>>>>> Cheers >>>>>> Rob >>>>>> >>>>>> >>>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>>>>> >>>>>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>>> >>>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>>>> fixes the problem. >>>>>>>> >>>>>>>> I can resolv my internal dns zones again:-) >>>>>>>> >>>>>>>> Many thanx. >>>>>>>> >>>>>>>> Since this problem happened every time I tried to update the freeipa >>>>>>>> server. >>>>>>>> I could re-run the update with some debug options if you like so you >>>>>>>> can >>>>>>>> pinpoint what goes wrong with the update script if you like. >>>>>>>> >>>>>>>> >>>>>>>> I have re-build some packages in mkosek's CORP so now you should >>>>>>> not see >>>>>>> encounter dependency problems. Simple 'yum upgrade' should give you >>>>>>> all >>>>>>> the >>>>>>> required packages. >>>>>>> >>>>>>> We are looking at other problems in upgrade process right now so there >>>>>>> is >>>>>>> not much to test except package dependencies. From rob.verduijn at gmail.com Wed Nov 5 15:17:06 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 5 Nov 2014 16:17:06 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A3E36.4070709@redhat.com> References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3E36.4070709@redhat.com> Message-ID: Hello, I use only a single freeipa server (so no replica to bother) Internal zones worked before the update After the update, internal zones no longer worked. After reverting back the snapshot the internal zones worked again, no additional actions were needed. Rob 2014-11-05 16:11 GMT+01:00 Petr Spacek : > Hello, > > Rob V., you did not answered to my question when DNS worked for you last > time. Did it work right after reverting the snapshot? > > Petr^2 Spacek > > > On 5.11.2014 16:09, Rob Verduijn wrote: > >> Hello again, >> >> I don't know about foreman upstream, the current version that I am using >> included in the katello installation is 1.6 >> And the foreman manpage still requires the configuration of the >> realm-smart-proxy. >> http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm >> >> About the snapshot: >> I removed all the katello entries from my current freeipa installation ( I >> peeked in the script to see what it did ) >> - user (foreman-realm) >> - role (Smart Host Proxy Manager) >> - privilege (Smart Host Proxy Management) >> - 3 custom permissions ( modify host password, write host certificate, >> modify host userclass ) >> applied the update to freeipa 4.1. >> my local dns zones did not resolv again >> running the ipa-ldap-updater did not fix it >> >> So I guess that it is not due to the katello integration or the >> realm-smart-proxy script. >> >> Rob >> >> 2014-11-05 14:39 GMT+01:00 Petr Spacek : >> >> On 4.11.2014 17:15, Rob Verduijn wrote: >>> >>> The problem with 'foreman-prepare-realm' and freeipa was that it claimed >>>> that a few o thef permissions required did not exist when it tried to >>>> add >>>> them to the 'smart proxy host management' privilege. >>>> >>>> I think it was because the permissions were all in lower case without >>>> the >>>> 'System: ' prefix. This is just an assumption since I did not get to >>>> work >>>> even after adding them manually. So I figured to try it again after >>>> reverting back to 3.3.5. >>>> >>>> After downgrading I learned that it did not work due to a bug in a ruby >>>> script. (fixed by commenting out line 505-506 >>>> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see >>>> https://bugs.ruby-lang.org/issues/8182 and >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) >>>> >>>> After which I tried the upgrade again. >>>> >>>> regarding >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>>> I did look again using the kredentials as mentioned in step 4. and saw >>>> only >>>> 3 objects (1x idnsConfigObject 2x nsContainer) >>>> When using admin credentials I saw all the dns zone entries. >>>> >>>> I can see the zone entries in the ipa gui. >>>> >>>> Also when I look at the permissions in ipa there are no longer any >>>> permissions that have the 'System: ' prefix. >>>> >>>> >>> AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x >>> because it was obsoleted by 'native' proxy delivered by Foreman upstream. >>> >>> Am I right, Rob (Crittenden)? :-) >>> >>> Anyway, back to your DNS problem. Did it worked before you installed >>> Foreman proxy? Or not? I.e. is it working when you revert the snapshot? >>> >>> Do you have other replicas in the replication topology? Please keep in >>> mind that changes in LDAP (including changes to permissions) are >>> replicated >>> so reverting one VM and not others is not necessarily enough. >>> >>> Petr^2 Spacek >>> >>> >>> 2014-11-04 15:52 GMT+01:00 Petr Spacek : >>> >>>> >>>> On 4.11.2014 15:27, Rob Verduijn wrote: >>>> >>>>> >>>>> Hello again, >>>>> >>>>>> >>>>>> I've managed to integrate my katello configuration with freeipa. >>>>>> Now I not only use freeipa authentication in katello but also when a >>>>>> host >>>>>> is defined in katello it automagically gets created in the freeipa >>>>>> realm , >>>>>> certs, otp,dns all working great. >>>>>> >>>>>> however, to obtain all this integration greatness I had to downgrade >>>>>> my >>>>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm >>>>>> integration tool (foreman-prepare-realm) is not capable of dealing >>>>>> with >>>>>> 4.X >>>>>> versions of freeipa. >>>>>> >>>>>> It would be nice if you could get tell us more details about the >>>>>> >>>>> problem >>>>> you had with Katello, AFAIK we are not aware of any. >>>>> >>>>> And now the named-pkcs11 again does not see my internal zones. >>>>> >>>>> >>>>>> This page >>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >>>>>> thinks >>>>>> I should contact the freeipa-users list >>>>>> >>>>>> >>>>>> Do I understand correctly that you did all the steps 0-4 >>>>> successfully and >>>>> then you found out that you can't see DNS objects in LDAP (step 5) when >>>>> using ldapsearch with DNS principal? >>>>> >>>>> Can you see the objects in IPA web UI or CLI? If it is the case then we >>>>> will need help from LDAP ACI expert (pviktori? :-). >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>> The command 'ipa-ldap-updater >>>>> >>>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. >>>>>> and the command 'ipa-ldap-updater' didn't fix it either. >>>>>> >>>>>> So I am now stuck at freeipa 3.3.5 again (with a working katello >>>>>> integration, so I got some mixed emotions about it) >>>>>> Any ideas anyone ? >>>>>> Rob >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>>> I've tested the update again. >>>>>>> >>>>>>> The bind-utils conflict is still there when I issue "yum update >>>>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page >>>>>>> http://www.freeipa.org/page/Downloads#Upgrading ) >>>>>>> >>>>>>> 'yum update' works fine >>>>>>> >>>>>>> My internal zones didn't resolv after the update >>>>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>>> didn't >>>>>>> fix >>>>>>> it >>>>>>> ipa-ldap-updater did fix the 'access control instructions' and my >>>>>>> internal >>>>>>> dns zones started to resolv again :-) >>>>>>> >>>>>>> Cheers >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : >>>>>>> >>>>>>> On 29.10.2014 16:46, Rob Verduijn wrote: >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update >>>>>>>>> fixes the problem. >>>>>>>>> >>>>>>>>> I can resolv my internal dns zones again:-) >>>>>>>>> >>>>>>>>> Many thanx. >>>>>>>>> >>>>>>>>> Since this problem happened every time I tried to update the >>>>>>>>> freeipa >>>>>>>>> server. >>>>>>>>> I could re-run the update with some debug options if you like so >>>>>>>>> you >>>>>>>>> can >>>>>>>>> pinpoint what goes wrong with the update script if you like. >>>>>>>>> >>>>>>>>> >>>>>>>>> I have re-build some packages in mkosek's CORP so now you should >>>>>>>>> >>>>>>>> not see >>>>>>>> encounter dependency problems. Simple 'yum upgrade' should give you >>>>>>>> all >>>>>>>> the >>>>>>>> required packages. >>>>>>>> >>>>>>>> We are looking at other problems in upgrade process right now so >>>>>>>> there >>>>>>>> is >>>>>>>> not much to test except package dependencies. >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at redhat.com Wed Nov 5 15:17:30 2014 From: stephen at redhat.com (Stephen Benjamin) Date: Wed, 5 Nov 2014 16:17:30 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A3737.5000108@redhat.com> References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> Message-ID: <20141105151730.GC3594@origin.bitbin.de> On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: > >> Also when I look at the permissions in ipa there are no longer any > >> permissions that have the 'System: ' prefix. > > > > AFAIK the foreman proxy is not necessary (and not supported) with IPA > > 4.x because it was obsoleted by 'native' proxy delivered by Foreman > > upstream. > > > > Am I right, Rob (Crittenden)? :-) > > I believe he's referring to the native smart proxy here. It includes a > script to setup permissions. I guess it hasn't been tested against a 4.x > IPA master. The permissions have changed names in FreeIPA 4.0, which means the script won't work. I've tested this one against 4.1 on F21 and it works: https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm There's an open pull request against foreman's Smart Proxy to include that in the next release: https://github.com/theforeman/smart-proxy/pull/231 -- Stephen Benjamin ______________________________________________________ Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn Handelsregister: Amtsgericht M?nchen, HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From technolengy at gmail.com Wed Nov 5 15:19:30 2014 From: technolengy at gmail.com (Steve Nolen) Date: Wed, 5 Nov 2014 07:19:30 -0800 Subject: [Freeipa-users] trouble editing user details after migrating from openldap Message-ID: Hi All! I'm looking at migrating from openldap to freeipa (currently using 3.3.3 on centos7, installed from the default centos repos, as I'd prefer to use centos over fedora) and I have a bit of a snag after importing users with migration-ds: I can't edit the details of migrated users in the web ui (but I can via `ipa user-mod`). Steps to reproduce: 1. kinit admin 2. ipa config-mod --enable-migration=TRUE 3. ipa migrate-ds --base-dn='dc=example,dc=com' --user-container='ou=People' --group-container='ou=Group' --bind-dn='cn=admin' --with-compat --schema='RFC2307' 4. ipa config-mod --enable-migration=FALSE 5. ipa user-mod test1 --last=LastName1 (success) 6. visit web ui (logging in as admin), user test1 has "LastName1" as "last name" field, but no fields on this page are editable. 7. create new user via web ui "test2". 8. all fields are editable for user test2. Based on the success from step 5, it would appear that the admin user has the rights to modify test1's details, but the web ui disagrees? Thanks! Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Wed Nov 5 15:19:54 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 05 Nov 2014 10:19:54 -0500 Subject: [Freeipa-users] Trust relationship issues Message-ID: <20141105151954.6090901.90027.7560@gmail.com> Sending again? Previous mail hot mangled by blackberry? ? I have two AD and would like to retain that redundancy within IPA after establishing trust relationship. How would one achieve that? I have attempted the following: [root at ipa3-yyz-int ~]# ipa dnszone-add example.local --name-server=srvyyzdc02.example.local --name-server=srvyyzdc01.example.local --admin-email='systemadmin at example.com' --force --forwarder=10.10.10.90 --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.90 --ip-address=10.10.10.91 ipa: ERROR: invalid 'idnssoamname': Only one value is allowed And got the following error above This however works ipa dnszone-add example.local --name-server=srvyyzdc02.example.local --admin-email='systemadmin at example.com' --force --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.91 What should I have done to get redundancy working? If this is not possible currently, any chance it can be implemented some day? William From stephen at redhat.com Wed Nov 5 15:20:14 2014 From: stephen at redhat.com (Stephen Benjamin) Date: Wed, 5 Nov 2014 16:20:14 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> Message-ID: <20141105152014.GD3594@origin.bitbin.de> On Wed, Nov 05, 2014 at 04:09:18PM +0100, Rob Verduijn wrote: > Hello again, > > I don't know about foreman upstream, the current version that I am using > included in the katello installation is 1.6 > And the foreman manpage still requires the configuration of the > realm-smart-proxy. > http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm > > About the snapshot: > I removed all the katello entries from my current freeipa installation ( I > peeked in the script to see what it did ) > - user (foreman-realm) > - role (Smart Host Proxy Manager) > - privilege (Smart Host Proxy Management) > - 3 custom permissions ( modify host password, write host certificate, > modify host userclass ) > applied the update to freeipa 4.1. > my local dns zones did not resolv again > running the ipa-ldap-updater did not fix it It's more like 12 permissions for that privilege, the complaints of missing permissions you saw is because they've changed names in FreeIPA 4, you can try this script instead: https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm > So I guess that it is not due to the katello integration or the > realm-smart-proxy script. > > Rob > > 2014-11-05 14:39 GMT+01:00 Petr Spacek : > > > On 4.11.2014 17:15, Rob Verduijn wrote: > > > >> The problem with 'foreman-prepare-realm' and freeipa was that it claimed > >> that a few o thef permissions required did not exist when it tried to add > >> them to the 'smart proxy host management' privilege. > >> > >> I think it was because the permissions were all in lower case without the > >> 'System: ' prefix. This is just an assumption since I did not get to work > >> even after adding them manually. So I figured to try it again after > >> reverting back to 3.3.5. > >> > >> After downgrading I learned that it did not work due to a bug in a ruby > >> script. (fixed by commenting out line 505-506 > >> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see > >> https://bugs.ruby-lang.org/issues/8182 and > >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) > >> > >> After which I tried the upgrade again. > >> > >> regarding > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > >> I did look again using the kredentials as mentioned in step 4. and saw > >> only > >> 3 objects (1x idnsConfigObject 2x nsContainer) > >> When using admin credentials I saw all the dns zone entries. > >> > >> I can see the zone entries in the ipa gui. > >> > >> Also when I look at the permissions in ipa there are no longer any > >> permissions that have the 'System: ' prefix. > >> > > > > AFAIK the foreman proxy is not necessary (and not supported) with IPA 4.x > > because it was obsoleted by 'native' proxy delivered by Foreman upstream. > > > > Am I right, Rob (Crittenden)? :-) > > > > Anyway, back to your DNS problem. Did it worked before you installed > > Foreman proxy? Or not? I.e. is it working when you revert the snapshot? > > > > Do you have other replicas in the replication topology? Please keep in > > mind that changes in LDAP (including changes to permissions) are replicated > > so reverting one VM and not others is not necessarily enough. > > > > Petr^2 Spacek > > > > > > 2014-11-04 15:52 GMT+01:00 Petr Spacek : > >> > >> On 4.11.2014 15:27, Rob Verduijn wrote: > >>> > >>> Hello again, > >>>> > >>>> I've managed to integrate my katello configuration with freeipa. > >>>> Now I not only use freeipa authentication in katello but also when a > >>>> host > >>>> is defined in katello it automagically gets created in the freeipa > >>>> realm , > >>>> certs, otp,dns all working great. > >>>> > >>>> however, to obtain all this integration greatness I had to downgrade my > >>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm > >>>> integration tool (foreman-prepare-realm) is not capable of dealing with > >>>> 4.X > >>>> versions of freeipa. > >>>> > >>>> It would be nice if you could get tell us more details about the > >>> problem > >>> you had with Katello, AFAIK we are not aware of any. > >>> > >>> And now the named-pkcs11 again does not see my internal zones. > >>> > >>>> > >>>> This page > >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > >>>> thinks > >>>> I should contact the freeipa-users list > >>>> > >>>> > >>> Do I understand correctly that you did all the steps 0-4 successfully and > >>> then you found out that you can't see DNS objects in LDAP (step 5) when > >>> using ldapsearch with DNS principal? > >>> > >>> Can you see the objects in IPA web UI or CLI? If it is the case then we > >>> will need help from LDAP ACI expert (pviktori? :-). > >>> > >>> Petr^2 Spacek > >>> > >>> > >>> The command 'ipa-ldap-updater > >>> > >>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. > >>>> and the command 'ipa-ldap-updater' didn't fix it either. > >>>> > >>>> So I am now stuck at freeipa 3.3.5 again (with a working katello > >>>> integration, so I got some mixed emotions about it) > >>>> Any ideas anyone ? > >>>> Rob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : > >>>> > >>>> Hello, > >>>> > >>>>> > >>>>> I've tested the update again. > >>>>> > >>>>> The bind-utils conflict is still there when I issue "yum update > >>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page > >>>>> http://www.freeipa.org/page/Downloads#Upgrading ) > >>>>> > >>>>> 'yum update' works fine > >>>>> > >>>>> My internal zones didn't resolv after the update > >>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update didn't > >>>>> fix > >>>>> it > >>>>> ipa-ldap-updater did fix the 'access control instructions' and my > >>>>> internal > >>>>> dns zones started to resolv again :-) > >>>>> > >>>>> Cheers > >>>>> Rob > >>>>> > >>>>> > >>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : > >>>>> > >>>>> On 29.10.2014 16:46, Rob Verduijn wrote: > >>>>> > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>>> > >>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > >>>>>>> fixes the problem. > >>>>>>> > >>>>>>> I can resolv my internal dns zones again:-) > >>>>>>> > >>>>>>> Many thanx. > >>>>>>> > >>>>>>> Since this problem happened every time I tried to update the freeipa > >>>>>>> server. > >>>>>>> I could re-run the update with some debug options if you like so you > >>>>>>> can > >>>>>>> pinpoint what goes wrong with the update script if you like. > >>>>>>> > >>>>>>> > >>>>>>> I have re-build some packages in mkosek's CORP so now you should > >>>>>> not see > >>>>>> encounter dependency problems. Simple 'yum upgrade' should give you > >>>>>> all > >>>>>> the > >>>>>> required packages. > >>>>>> > >>>>>> We are looking at other problems in upgrade process right now so there > >>>>>> is > >>>>>> not much to test except package dependencies. > >>>>>> > >>>>> > -- > 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 -- Stephen Benjamin ______________________________________________________ Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn Handelsregister: Amtsgericht M?nchen, HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rcritten at redhat.com Wed Nov 5 15:20:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Nov 2014 10:20:36 -0500 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <20141105151730.GC3594@origin.bitbin.de> References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> Message-ID: <545A4044.4050400@redhat.com> Stephen Benjamin wrote: > On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: >>>> Also when I look at the permissions in ipa there are no longer any >>>> permissions that have the 'System: ' prefix. >>> >>> AFAIK the foreman proxy is not necessary (and not supported) with IPA >>> 4.x because it was obsoleted by 'native' proxy delivered by Foreman >>> upstream. >>> >>> Am I right, Rob (Crittenden)? :-) >> >> I believe he's referring to the native smart proxy here. It includes a >> script to setup permissions. I guess it hasn't been tested against a 4.x >> IPA master. > > The permissions have changed names in FreeIPA 4.0, which means the > script won't work. I've tested this one against 4.1 on F21 and it > works: > > https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm > > There's an open pull request against foreman's Smart Proxy to include > that in the next release: > > https://github.com/theforeman/smart-proxy/pull/231 Great news! As an upstream we should probably try to avoid breaking other packages in the future. Do you have any suggestions on how we might avoid this in the future (stable permission names would be one)? rob From rob.verduijn at gmail.com Wed Nov 5 15:20:52 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 5 Nov 2014 16:20:52 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <20141105151730.GC3594@origin.bitbin.de> References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> Message-ID: Hello, Yes I noticed the name change it took me a while to realise it was a known ruby bug in katello that caused the real problem. I also checked after I updated the 'katello integrated' update from 3.3.5 to 4.1 and the permissions were neatly renamed to their new counterparts. However the internal dns no longer worked :( Rob 2014-11-05 16:17 GMT+01:00 Stephen Benjamin : > On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: > > >> Also when I look at the permissions in ipa there are no longer any > > >> permissions that have the 'System: ' prefix. > > > > > > AFAIK the foreman proxy is not necessary (and not supported) with IPA > > > 4.x because it was obsoleted by 'native' proxy delivered by Foreman > > > upstream. > > > > > > Am I right, Rob (Crittenden)? :-) > > > > I believe he's referring to the native smart proxy here. It includes a > > script to setup permissions. I guess it hasn't been tested against a 4.x > > IPA master. > > The permissions have changed names in FreeIPA 4.0, which means the > script won't work. I've tested this one against 4.1 on F21 and it > works: > > > https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm > > There's an open pull request against foreman's Smart Proxy to include > that in the next release: > > https://github.com/theforeman/smart-proxy/pull/231 > > > > > -- > Stephen Benjamin > > ______________________________________________________ > Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn > Handelsregister: Amtsgericht M?nchen, HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, > Michael O'Neill, Charles Peters > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 5 15:25:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Nov 2014 16:25:36 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> Message-ID: <545A4170.1070109@redhat.com> On 5.11.2014 16:20, Rob Verduijn wrote: > Hello, > > Yes I noticed the name change it took me a while to realise it was a known > ruby bug in katello that caused the real problem. > > I also checked after I updated the 'katello integrated' update from 3.3.5 > to 4.1 and the permissions were neatly renamed to their new counterparts. > > However the internal dns no longer worked :( So the permissions broke after upgrade to 4.1, right? pviktori, can you give us some advice? Thanks! Petr^2 Spacek > Rob > > 2014-11-05 16:17 GMT+01:00 Stephen Benjamin : > >> On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: >>>>> Also when I look at the permissions in ipa there are no longer any >>>>> permissions that have the 'System: ' prefix. >>>> >>>> AFAIK the foreman proxy is not necessary (and not supported) with IPA >>>> 4.x because it was obsoleted by 'native' proxy delivered by Foreman >>>> upstream. >>>> >>>> Am I right, Rob (Crittenden)? :-) >>> >>> I believe he's referring to the native smart proxy here. It includes a >>> script to setup permissions. I guess it hasn't been tested against a 4.x >>> IPA master. >> >> The permissions have changed names in FreeIPA 4.0, which means the >> script won't work. I've tested this one against 4.1 on F21 and it >> works: >> >> >> https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm >> >> There's an open pull request against foreman's Smart Proxy to include >> that in the next release: >> >> https://github.com/theforeman/smart-proxy/pull/231-- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek From rob.verduijn at gmail.com Wed Nov 5 15:27:19 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 5 Nov 2014 16:27:19 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <20141105152014.GD3594@origin.bitbin.de> References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <20141105152014.GD3594@origin.bitbin.de> Message-ID: Great news about the script. I will as soon as I get the upgrade to 4.1 to work with internal dns support. yup 12 default permissions + 3 custom permissions in the smart-host-proxy-management privilege I guessed I leave those 12 default permissions since I expect it might break things when I remove those :P Rob 2014-11-05 16:20 GMT+01:00 Stephen Benjamin : > On Wed, Nov 05, 2014 at 04:09:18PM +0100, Rob Verduijn wrote: > > Hello again, > > > > I don't know about foreman upstream, the current version that I am using > > included in the katello installation is 1.6 > > And the foreman manpage still requires the configuration of the > > realm-smart-proxy. > > http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm > > > > About the snapshot: > > I removed all the katello entries from my current freeipa installation ( > I > > peeked in the script to see what it did ) > > - user (foreman-realm) > > - role (Smart Host Proxy Manager) > > - privilege (Smart Host Proxy Management) > > - 3 custom permissions ( modify host password, write host certificate, > > modify host userclass ) > > applied the update to freeipa 4.1. > > my local dns zones did not resolv again > > running the ipa-ldap-updater did not fix it > > It's more like 12 permissions for that privilege, the complaints of > missing permissions you saw is because they've changed names in FreeIPA > 4, you can try this script instead: > > https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm > > > > So I guess that it is not due to the katello integration or the > > realm-smart-proxy script. > > > > Rob > > > > 2014-11-05 14:39 GMT+01:00 Petr Spacek : > > > > > On 4.11.2014 17:15, Rob Verduijn wrote: > > > > > >> The problem with 'foreman-prepare-realm' and freeipa was that it > claimed > > >> that a few o thef permissions required did not exist when it tried to > add > > >> them to the 'smart proxy host management' privilege. > > >> > > >> I think it was because the permissions were all in lower case without > the > > >> 'System: ' prefix. This is just an assumption since I did not get to > work > > >> even after adding them manually. So I figured to try it again after > > >> reverting back to 3.3.5. > > >> > > >> After downgrading I learned that it did not work due to a bug in a > ruby > > >> script. (fixed by commenting out line 505-506 > > >> in /usr/share/ruby/xmlrpc/client.rb on the katello host, see > > >> https://bugs.ruby-lang.org/issues/8182 and > > >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) > > >> > > >> After which I tried the upgrade again. > > >> > > >> regarding > > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > > >> I did look again using the kredentials as mentioned in step 4. and saw > > >> only > > >> 3 objects (1x idnsConfigObject 2x nsContainer) > > >> When using admin credentials I saw all the dns zone entries. > > >> > > >> I can see the zone entries in the ipa gui. > > >> > > >> Also when I look at the permissions in ipa there are no longer any > > >> permissions that have the 'System: ' prefix. > > >> > > > > > > AFAIK the foreman proxy is not necessary (and not supported) with IPA > 4.x > > > because it was obsoleted by 'native' proxy delivered by Foreman > upstream. > > > > > > Am I right, Rob (Crittenden)? :-) > > > > > > Anyway, back to your DNS problem. Did it worked before you installed > > > Foreman proxy? Or not? I.e. is it working when you revert the snapshot? > > > > > > Do you have other replicas in the replication topology? Please keep in > > > mind that changes in LDAP (including changes to permissions) are > replicated > > > so reverting one VM and not others is not necessarily enough. > > > > > > Petr^2 Spacek > > > > > > > > > 2014-11-04 15:52 GMT+01:00 Petr Spacek : > > >> > > >> On 4.11.2014 15:27, Rob Verduijn wrote: > > >>> > > >>> Hello again, > > >>>> > > >>>> I've managed to integrate my katello configuration with freeipa. > > >>>> Now I not only use freeipa authentication in katello but also when a > > >>>> host > > >>>> is defined in katello it automagically gets created in the freeipa > > >>>> realm , > > >>>> certs, otp,dns all working great. > > >>>> > > >>>> however, to obtain all this integration greatness I had to > downgrade my > > >>>> freeipa to 3.3.5 again (revert snapshot) because the katello realm > > >>>> integration tool (foreman-prepare-realm) is not capable of dealing > with > > >>>> 4.X > > >>>> versions of freeipa. > > >>>> > > >>>> It would be nice if you could get tell us more details about the > > >>> problem > > >>> you had with Katello, AFAIK we are not aware of any. > > >>> > > >>> And now the named-pkcs11 again does not see my internal zones. > > >>> > > >>>> > > >>>> This page > > >>>> > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > > >>>> thinks > > >>>> I should contact the freeipa-users list > > >>>> > > >>>> > > >>> Do I understand correctly that you did all the steps 0-4 > successfully and > > >>> then you found out that you can't see DNS objects in LDAP (step 5) > when > > >>> using ldapsearch with DNS principal? > > >>> > > >>> Can you see the objects in IPA web UI or CLI? If it is the case then > we > > >>> will need help from LDAP ACI expert (pviktori? :-). > > >>> > > >>> Petr^2 Spacek > > >>> > > >>> > > >>> The command 'ipa-ldap-updater > > >>> > > >>>> /usr/share/ipa/updates/55-pbacmemberof.update' didn't fix it. > > >>>> and the command 'ipa-ldap-updater' didn't fix it either. > > >>>> > > >>>> So I am now stuck at freeipa 3.3.5 again (with a working katello > > >>>> integration, so I got some mixed emotions about it) > > >>>> Any ideas anyone ? > > >>>> Rob > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> 2014-10-29 22:14 GMT+01:00 Rob Verduijn : > > >>>> > > >>>> Hello, > > >>>> > > >>>>> > > >>>>> I've tested the update again. > > >>>>> > > >>>>> The bind-utils conflict is still there when I issue "yum update > > >>>>> freeipa-server" ( as indicated on the freeipa 4.1 download page > > >>>>> http://www.freeipa.org/page/Downloads#Upgrading ) > > >>>>> > > >>>>> 'yum update' works fine > > >>>>> > > >>>>> My internal zones didn't resolv after the update > > >>>>> ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > didn't > > >>>>> fix > > >>>>> it > > >>>>> ipa-ldap-updater did fix the 'access control instructions' and my > > >>>>> internal > > >>>>> dns zones started to resolv again :-) > > >>>>> > > >>>>> Cheers > > >>>>> Rob > > >>>>> > > >>>>> > > >>>>> 2014-10-29 18:14 GMT+01:00 Petr Spacek : > > >>>>> > > >>>>> On 29.10.2014 16:46, Rob Verduijn wrote: > > >>>>> > > >>>>>> > > >>>>>> Hello, > > >>>>>> > > >>>>>>> > > >>>>>>> # ipa-ldap-updater /usr/share/ipa/updates/55-pbacmemberof.update > > >>>>>>> fixes the problem. > > >>>>>>> > > >>>>>>> I can resolv my internal dns zones again:-) > > >>>>>>> > > >>>>>>> Many thanx. > > >>>>>>> > > >>>>>>> Since this problem happened every time I tried to update the > freeipa > > >>>>>>> server. > > >>>>>>> I could re-run the update with some debug options if you like so > you > > >>>>>>> can > > >>>>>>> pinpoint what goes wrong with the update script if you like. > > >>>>>>> > > >>>>>>> > > >>>>>>> I have re-build some packages in mkosek's CORP so now you should > > >>>>>> not see > > >>>>>> encounter dependency problems. Simple 'yum upgrade' should give > you > > >>>>>> all > > >>>>>> the > > >>>>>> required packages. > > >>>>>> > > >>>>>> We are looking at other problems in upgrade process right now so > there > > >>>>>> is > > >>>>>> not much to test except package dependencies. > > >>>>>> > > >>>>> > > > -- > > 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 > > > -- > Stephen Benjamin > > ______________________________________________________ > Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn > Handelsregister: Amtsgericht M?nchen, HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, > Michael O'Neill, Charles Peters > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 5 15:31:06 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 05 Nov 2014 16:31:06 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <544FCB4A.8030900@redhat.com> <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3E36.4070709@redhat.com> Message-ID: <545A42BA.3050305@redhat.com> Hello, can you send content of these entries (I need mainly member and memberof attributes)?: DN: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=com DN: krbprincipalname=DNS/example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com DN: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=com On 05/11/14 16:17, Rob Verduijn wrote: > Hello, > > I use only a single freeipa server (so no replica to bother) > > Internal zones worked before the update > After the update, internal zones no longer worked. > After reverting back the snapshot the internal zones worked again, no > additional actions were needed. > > Rob > > 2014-11-05 16:11 GMT+01:00 Petr Spacek >: > > Hello, > > Rob V., you did not answered to my question when DNS worked for > you last time. Did it work right after reverting the snapshot? > > Petr^2 Spacek > > > On 5.11.2014 16:09, Rob Verduijn wrote: > > Hello again, > > I don't know about foreman upstream, the current version that > I am using > included in the katello installation is 1.6 > And the foreman manpage still requires the configuration of the > realm-smart-proxy. > http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm > > About the snapshot: > I removed all the katello entries from my current freeipa > installation ( I > peeked in the script to see what it did ) > - user (foreman-realm) > - role (Smart Host Proxy Manager) > - privilege (Smart Host Proxy Management) > - 3 custom permissions ( modify host password, write host > certificate, > modify host userclass ) > applied the update to freeipa 4.1. > my local dns zones did not resolv again > running the ipa-ldap-updater did not fix it > > So I guess that it is not due to the katello integration or the > realm-smart-proxy script. > > Rob > > 2014-11-05 14:39 GMT+01:00 Petr Spacek >: > > On 4.11.2014 17:15, Rob Verduijn wrote: > > The problem with 'foreman-prepare-realm' and freeipa > was that it claimed > that a few o thef permissions required did not exist > when it tried to add > them to the 'smart proxy host management' privilege. > > I think it was because the permissions were all in > lower case without the > 'System: ' prefix. This is just an assumption since I > did not get to work > even after adding them manually. So I figured to try > it again after > reverting back to 3.3.5. > > After downgrading I learned that it did not work due > to a bug in a ruby > script. (fixed by commenting out line 505-506 > in /usr/share/ruby/xmlrpc/client.rb on the katello > host, see > https://bugs.ruby-lang.org/issues/8182 and > https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) > > After which I tried the upgrade again. > > regarding > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > I did look again using the kredentials as mentioned in > step 4. and saw > only > 3 objects (1x idnsConfigObject 2x nsContainer) > When using admin credentials I saw all the dns zone > entries. > > I can see the zone entries in the ipa gui. > > Also when I look at the permissions in ipa there are > no longer any > permissions that have the 'System: ' prefix. > > > AFAIK the foreman proxy is not necessary (and not > supported) with IPA 4.x > because it was obsoleted by 'native' proxy delivered by > Foreman upstream. > > Am I right, Rob (Crittenden)? :-) > > Anyway, back to your DNS problem. Did it worked before you > installed > Foreman proxy? Or not? I.e. is it working when you revert > the snapshot? > > Do you have other replicas in the replication topology? > Please keep in > mind that changes in LDAP (including changes to > permissions) are replicated > so reverting one VM and not others is not necessarily enough. > > Petr^2 Spacek > > > 2014-11-04 15:52 GMT+01:00 Petr Spacek > >: > > > On 4.11.2014 15:27, Rob Verduijn wrote: > > > Hello again, > > > I've managed to integrate my katello > configuration with freeipa. > Now I not only use freeipa authentication in > katello but also when a > host > is defined in katello it automagically gets > created in the freeipa > realm , > certs, otp,dns all working great. > > however, to obtain all this integration > greatness I had to downgrade my > freeipa to 3.3.5 again (revert snapshot) > because the katello realm > integration tool (foreman-prepare-realm) is > not capable of dealing with > 4.X > versions of freeipa. > > It would be nice if you could get tell us > more details about the > > problem > you had with Katello, AFAIK we are not aware of any. > > And now the named-pkcs11 again does not see my > internal zones. > > > This page > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart > thinks > I should contact the freeipa-users list > > > Do I understand correctly that you did all the > steps 0-4 successfully and > then you found out that you can't see DNS objects > in LDAP (step 5) when > using ldapsearch with DNS principal? > > Can you see the objects in IPA web UI or CLI? If > it is the case then we > will need help from LDAP ACI expert (pviktori? :-). > > Petr^2 Spacek > > > The command 'ipa-ldap-updater > > /usr/share/ipa/updates/55-pbacmemberof.update' > didn't fix it. > and the command 'ipa-ldap-updater' didn't fix > it either. > > So I am now stuck at freeipa 3.3.5 again (with > a working katello > integration, so I got some mixed emotions > about it) > Any ideas anyone ? > Rob > > > > > > > 2014-10-29 22:14 GMT+01:00 Rob Verduijn > >: > > Hello, > > > I've tested the update again. > > The bind-utils conflict is still there > when I issue "yum update > freeipa-server" ( as indicated on the > freeipa 4.1 download page > http://www.freeipa.org/page/Downloads#Upgrading > ) > > 'yum update' works fine > > My internal zones didn't resolv after the > update > ipa-ldap-updater > /usr/share/ipa/updates/55-pbacmemberof.update > didn't > fix > it > ipa-ldap-updater did fix the 'access > control instructions' and my > internal > dns zones started to resolv again :-) > > Cheers > Rob > > > 2014-10-29 18:14 GMT+01:00 Petr Spacek > >: > > On 29.10.2014 16:46, Rob Verduijn wrote: > > > Hello, > > > # ipa-ldap-updater > /usr/share/ipa/updates/55-pbacmemberof.update > fixes the problem. > > I can resolv my internal dns zones > again:-) > > Many thanx. > > Since this problem happened every > time I tried to update the freeipa > server. > I could re-run the update with > some debug options if you like so you > can > pinpoint what goes wrong with the > update script if you like. > > > I have re-build some packages in > mkosek's CORP so now you should > > not see > encounter dependency problems. Simple > 'yum upgrade' should give you > all > the > required packages. > > We are looking at other problems in > upgrade process right now so there > is > not much to test except package > dependencies. > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at redhat.com Wed Nov 5 15:45:02 2014 From: stephen at redhat.com (Stephen Benjamin) Date: Wed, 5 Nov 2014 16:45:02 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A4044.4050400@redhat.com> References: <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> <545A4044.4050400@redhat.com> Message-ID: <20141105154502.GE3594@origin.bitbin.de> On Wed, Nov 05, 2014 at 10:20:36AM -0500, Rob Crittenden wrote: > Stephen Benjamin wrote: > > On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: > >>>> Also when I look at the permissions in ipa there are no longer any > >>>> permissions that have the 'System: ' prefix. > >>> > >>> AFAIK the foreman proxy is not necessary (and not supported) with IPA > >>> 4.x because it was obsoleted by 'native' proxy delivered by Foreman > >>> upstream. > >>> > >>> Am I right, Rob (Crittenden)? :-) > >> > >> I believe he's referring to the native smart proxy here. It includes a > >> script to setup permissions. I guess it hasn't been tested against a 4.x > >> IPA master. > > > > The permissions have changed names in FreeIPA 4.0, which means the > > script won't work. I've tested this one against 4.1 on F21 and it > > works: > > > > https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/sbin/foreman-prepare-realm > > > > There's an open pull request against foreman's Smart Proxy to include > > that in the next release: > > > > https://github.com/theforeman/smart-proxy/pull/231 > > Great news! As an upstream we should probably try to avoid breaking > other packages in the future. Do you have any suggestions on how we > might avoid this in the future (stable permission names would be one)? That kind of breakage seems fine between major versions. It would be nice if things would stay consistent -- but they generally do, so I don't really have any complaints. I think I should probably try to get to testing the betas of FreeIPA sooner with foreman. -- Stephen Benjamin ______________________________________________________ Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn Handelsregister: Amtsgericht M?nchen, HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rob.verduijn at gmail.com Wed Nov 5 16:22:34 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 5 Nov 2014 17:22:34 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: <545A4170.1070109@redhat.com> References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> <545A4170.1070109@redhat.com> Message-ID: I saw in the upstream foreman-prepare-realm script that the new permission names should include a prefix "System: " That Prefix is not there, what did change was that some permissions where no longer lower case only. ie in 3.3.5 the permission is 'write dns configuration' and in 4.1 it becomes 'Write DNS Configuration' Rob 2014-11-05 16:25 GMT+01:00 Petr Spacek : > On 5.11.2014 16:20, Rob Verduijn wrote: > >> Hello, >> >> Yes I noticed the name change it took me a while to realise it was a known >> ruby bug in katello that caused the real problem. >> >> I also checked after I updated the 'katello integrated' update from 3.3.5 >> to 4.1 and the permissions were neatly renamed to their new counterparts. >> >> However the internal dns no longer worked :( >> > > So the permissions broke after upgrade to 4.1, right? pviktori, can you > give us some advice? > > Thanks! > > Petr^2 Spacek > > Rob >> >> 2014-11-05 16:17 GMT+01:00 Stephen Benjamin : >> >> On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: >>> >>>> Also when I look at the permissions in ipa there are no longer any >>>>>> permissions that have the 'System: ' prefix. >>>>>> >>>>> >>>>> AFAIK the foreman proxy is not necessary (and not supported) with IPA >>>>> 4.x because it was obsoleted by 'native' proxy delivered by Foreman >>>>> upstream. >>>>> >>>>> Am I right, Rob (Crittenden)? :-) >>>>> >>>> >>>> I believe he's referring to the native smart proxy here. It includes a >>>> script to setup permissions. I guess it hasn't been tested against a 4.x >>>> IPA master. >>>> >>> >>> The permissions have changed names in FreeIPA 4.0, which means the >>> script won't work. I've tested this one against 4.1 on F21 and it >>> works: >>> >>> >>> https://raw.githubusercontent.com/stbenjam/smart-proxy/8278/ >>> sbin/foreman-prepare-realm >>> >>> There's an open pull request against foreman's Smart Proxy to include >>> that in the next release: >>> >>> https://github.com/theforeman/smart-proxy/pull/231-- >>> >> Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 5 16:43:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 05 Nov 2014 17:43:49 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <5450DD76.50908@redhat.com> <5450F0B9.9010907@redhat.com> <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3E36.4070709@redhat.com> <545A42BA.3050305@redhat.com> Message-ID: <545A53C5.8010505@redhat.com> Can you send me DNS related ACI in dc=tjako,dc=thuis On 05/11/14 17:08, Rob Verduijn wrote: > and here is the 4.1 version > > Rob > > > cat output-4.1.txt > # extended LDIF > # > # LDAPv3 > # base with > scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # DNS Servers, privileges, pbac, tjako.thuis > dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=tjako,dc=thuis > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup > cn: DNS Servers > description: DNS Servers > memberOf: cn=add dns entries,cn=permissions,cn=pbac,dc=tjako,dc=thuis > memberOf: cn=remove dns entries,cn=permissions,cn=pbac,dc=tjako,dc=thuis > memberOf: cn=update dns entries,cn=permissions,cn=pbac,dc=tjako,dc=thuis > memberOf: cn=Read DNS Entries,cn=permissions,cn=pbac,dc=tjako,dc=thuis > memberOf: cn=Write DNS > Configuration,cn=permissions,cn=pbac,dc=tjako,dc=thuis > member: > krbprincipalname=DNS/freeipa.tjako.thuis at TJAKO.THUIS,cn=services,cn=ac > counts,dc=tjako,dc=thuis > member: > krbprincipalname=ipa-dnskeysyncd/freeipa.tjako.thuis at TJAKO.THUIS,cn=se > rvices,cn=accounts,dc=tjako,dc=thuis > There are missing DNSSEC permissions. > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > # extended LDIF > # > # LDAPv3 > # base < > krbprincipalname=DNS/tjako.thuis at TJAKO.THUIS,cn=services,cn=accounts,dc=tjako,dc=thuis> > with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > matchedDN: cn=services,cn=accounts,dc=tjako,dc=thuis > > # numResponses: 1 > # extended LDIF > # > # LDAPv3 > # base > with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # Read DNS Entries, permissions, pbac, tjako.thuis > dn: cn=Read DNS Entries,cn=permissions,cn=pbac,dc=tjako,dc=thuis > objectClass: top > objectClass: groupofnames > objectClass: ipapermission > cn: Read DNS Entries > description: Read DNS entries > ipaPermissionType: SYSTEM > member: cn=DNS Administrators,cn=privileges,cn=pbac,dc=tjako,dc=thuis > member: cn=DNS Servers,cn=privileges,cn=pbac,dc=tjako,dc=thuis > member: cn=Smart Proxy Host > Management,cn=privileges,cn=pbac,dc=tjako,dc=thuis > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > 2014-11-05 16:31 GMT+01:00 Martin Basti >: > > Hello, > > can you send content of these entries (I need mainly member and > memberof attributes)?: > DN: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=com > DN: > krbprincipalname=DNS/example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com > > DN: cn=System: Read DNS > Entries,cn=permissions,cn=pbac,dc=example,dc=com > > > On 05/11/14 16:17, Rob Verduijn wrote: >> Hello, >> >> I use only a single freeipa server (so no replica to bother) >> >> Internal zones worked before the update >> After the update, internal zones no longer worked. >> After reverting back the snapshot the internal zones worked >> again, no additional actions were needed. >> >> Rob >> >> 2014-11-05 16:11 GMT+01:00 Petr Spacek > >: >> >> Hello, >> >> Rob V., you did not answered to my question when DNS worked >> for you last time. Did it work right after reverting the >> snapshot? >> >> Petr^2 Spacek >> >> >> On 5.11.2014 16:09, Rob Verduijn wrote: >> >> Hello again, >> >> I don't know about foreman upstream, the current version >> that I am using >> included in the katello installation is 1.6 >> And the foreman manpage still requires the configuration >> of the >> realm-smart-proxy. >> http://www.theforeman.org/manuals/1.6/index.html#4.3.9Realm >> >> About the snapshot: >> I removed all the katello entries from my current freeipa >> installation ( I >> peeked in the script to see what it did ) >> - user (foreman-realm) >> - role (Smart Host Proxy Manager) >> - privilege (Smart Host Proxy Management) >> - 3 custom permissions ( modify host password, write >> host certificate, >> modify host userclass ) >> applied the update to freeipa 4.1. >> my local dns zones did not resolv again >> running the ipa-ldap-updater did not fix it >> >> So I guess that it is not due to the katello integration >> or the >> realm-smart-proxy script. >> >> Rob >> >> 2014-11-05 14:39 GMT+01:00 Petr Spacek >> >: >> >> On 4.11.2014 17:15, Rob Verduijn wrote: >> >> The problem with 'foreman-prepare-realm' and >> freeipa was that it claimed >> that a few o thef permissions required did not >> exist when it tried to add >> them to the 'smart proxy host management' privilege. >> >> I think it was because the permissions were all >> in lower case without the >> 'System: ' prefix. This is just an assumption >> since I did not get to work >> even after adding them manually. So I figured to >> try it again after >> reverting back to 3.3.5. >> >> After downgrading I learned that it did not work >> due to a bug in a ruby >> script. (fixed by commenting out line 505-506 >> in /usr/share/ruby/xmlrpc/client.rb on the >> katello host, see >> https://bugs.ruby-lang.org/issues/8182 and >> https://bugzilla.redhat.com/show_bug.cgi?id=1071187 ) >> >> After which I tried the upgrade again. >> >> regarding >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >> I did look again using the kredentials as >> mentioned in step 4. and saw >> only >> 3 objects (1x idnsConfigObject 2x nsContainer) >> When using admin credentials I saw all the dns >> zone entries. >> >> I can see the zone entries in the ipa gui. >> >> Also when I look at the permissions in ipa there >> are no longer any >> permissions that have the 'System: ' prefix. >> >> >> AFAIK the foreman proxy is not necessary (and not >> supported) with IPA 4.x >> because it was obsoleted by 'native' proxy delivered >> by Foreman upstream. >> >> Am I right, Rob (Crittenden)? :-) >> >> Anyway, back to your DNS problem. Did it worked >> before you installed >> Foreman proxy? Or not? I.e. is it working when you >> revert the snapshot? >> >> Do you have other replicas in the replication >> topology? Please keep in >> mind that changes in LDAP (including changes to >> permissions) are replicated >> so reverting one VM and not others is not necessarily >> enough. >> >> Petr^2 Spacek >> >> >> 2014-11-04 15:52 GMT+01:00 Petr Spacek >> >: >> >> >> On 4.11.2014 15:27, Rob Verduijn wrote: >> >> >> Hello again, >> >> >> I've managed to integrate my katello >> configuration with freeipa. >> Now I not only use freeipa authentication >> in katello but also when a >> host >> is defined in katello it automagically >> gets created in the freeipa >> realm , >> certs, otp,dns all working great. >> >> however, to obtain all this integration >> greatness I had to downgrade my >> freeipa to 3.3.5 again (revert snapshot) >> because the katello realm >> integration tool (foreman-prepare-realm) >> is not capable of dealing with >> 4.X >> versions of freeipa. >> >> It would be nice if you could get tell >> us more details about the >> >> problem >> you had with Katello, AFAIK we are not aware >> of any. >> >> And now the named-pkcs11 again does not >> see my internal zones. >> >> >> This page >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart >> thinks >> I should contact the freeipa-users list >> >> >> Do I understand correctly that you did all >> the steps 0-4 successfully and >> then you found out that you can't see DNS >> objects in LDAP (step 5) when >> using ldapsearch with DNS principal? >> >> Can you see the objects in IPA web UI or CLI? >> If it is the case then we >> will need help from LDAP ACI expert >> (pviktori? :-). >> >> Petr^2 Spacek >> >> >> The command 'ipa-ldap-updater >> >> /usr/share/ipa/updates/55-pbacmemberof.update' >> didn't fix it. >> and the command 'ipa-ldap-updater' didn't >> fix it either. >> >> So I am now stuck at freeipa 3.3.5 again >> (with a working katello >> integration, so I got some mixed emotions >> about it) >> Any ideas anyone ? >> Rob >> >> >> >> >> >> >> 2014-10-29 22:14 GMT+01:00 Rob Verduijn >> > >: >> >> Hello, >> >> >> I've tested the update again. >> >> The bind-utils conflict is still >> there when I issue "yum update >> freeipa-server" ( as indicated on the >> freeipa 4.1 download page >> http://www.freeipa.org/page/Downloads#Upgrading >> ) >> >> 'yum update' works fine >> >> My internal zones didn't resolv after >> the update >> ipa-ldap-updater >> /usr/share/ipa/updates/55-pbacmemberof.update >> didn't >> fix >> it >> ipa-ldap-updater did fix the 'access >> control instructions' and my >> internal >> dns zones started to resolv again :-) >> >> Cheers >> Rob >> >> >> 2014-10-29 18:14 GMT+01:00 Petr >> Spacek > >: >> >> On 29.10.2014 16:46, Rob Verduijn >> wrote: >> >> >> Hello, >> >> >> # ipa-ldap-updater >> /usr/share/ipa/updates/55-pbacmemberof.update >> fixes the problem. >> >> I can resolv my internal dns >> zones again:-) >> >> Many thanx. >> >> Since this problem happened >> every time I tried to update >> the freeipa >> server. >> I could re-run the update >> with some debug options if >> you like so you >> can >> pinpoint what goes wrong with >> the update script if you like. >> >> >> I have re-build some >> packages in mkosek's CORP so >> now you should >> >> not see >> encounter dependency problems. >> Simple 'yum upgrade' should give you >> all >> the >> required packages. >> >> We are looking at other problems >> in upgrade process right now so there >> is >> not much to test except package >> dependencies. >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Wed Nov 5 18:37:35 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 5 Nov 2014 19:37:35 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: <5459E237.90803@redhat.com> References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> Message-ID: hi, On Wed, Nov 5, 2014 at 9:39 AM, Martin Kosek wrote: > On 11/04/2014 01:39 PM, Natxo Asenjo wrote: >> hi, >> >> On Mon, Nov 3, 2014 at 5:21 PM, Rob Crittenden wrote: >>> Natxo Asenjo wrote: >> >>>> How often does the crl list get generated? i still do not see recent data. >>> >>> This is controlled by ca.crl.MasterCRL.autoUpdateInterval which by >>> default is 240, so every 4 hours. >> >> mmm, still no new items in the https://kdc01.sub.domain.tld/ipa/crl/ >> site. Everything is stuck on june 28 2013. > > I would check PKI system logs and also look for any AVCs. There were SELinux > policy related bugs in the past which prevented creation of the CRLs in > /var/lib/ipa/pki-ca/publish/. Bingo! After disabling selinux this morning and waiting a few hours the crl was still not updated. So time to look at the logs. In /var/lib/pki-ca/logs/system I found lots of these messages: sterCRL-20141101-210000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:01:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-010000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:05:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-050000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:09:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-090000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:13:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-130000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:17:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-170000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [02/Nov/2014:21:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141102-210000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [03/Nov/2014:01:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141103-010000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [03/Nov/2014:05:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141103-050000.temp (Permission denied) 6489.CRLIssuingPoint-MasterCRL - [03/Nov/2014:09:00:00 CET] [20] [3] FileBasedPublisher: java.io.FileNotFoundException: /var/lib/ipa/pki-ca/publish/MasterCRL-20141103-090000.temp (Permission denied) Now I still need to find the solution :-) It does not appear to be a selinux problem: # restorecon -rv /var/lib/ipa/pki-ca/publish/ returns inmediately to the prompt, so no fixed contexts. Thanks, -- Groeten, natxo From natxo.asenjo at gmail.com Wed Nov 5 18:45:17 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 5 Nov 2014 19:45:17 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> Message-ID: On Wed, Nov 5, 2014 at 7:37 PM, Natxo Asenjo wrote: > 6489.CRLIssuingPoint-MasterCRL - [03/Nov/2014:09:00:00 CET] [20] [3] > FileBasedPublisher: java.io.FileNotFoundException: > /var/lib/ipa/pki-ca/publish/MasterCRL-20141103-090000.temp (Permission > denied) And I think I found it: https://fedorahosted.org/freeipa/ticket/3727 permissions of that folder: $ ls -ld publish/ drwxr-xr-x. 2 root root 73728 Jun 13 2013 publish/ I just changed them to pkiuser:pkiuser, let's see what the next run does. -- Groeten, natxo From natxo.asenjo at gmail.com Wed Nov 5 18:59:30 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 5 Nov 2014 19:59:30 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> Message-ID: hi, By the way, is it safe to rename this file: $ ls -lh /var/lib/pki-ca/logs/debug -rw-r-----. 1 pkiuser pkiuser 841M Nov 5 19:54 /var/lib/pki-ca/logs/debug It's quite big :-). Can I just rename it while the dirsrv is running and will a new one be created or do I have to stop the pki-cad daemon and then rename it? -- Regards, natxo From dpal at redhat.com Wed Nov 5 19:33:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Nov 2014 14:33:21 -0500 Subject: [Freeipa-users] trouble editing user details after migrating from openldap In-Reply-To: References: Message-ID: <545A7B81.6060104@redhat.com> On 11/05/2014 10:19 AM, Steve Nolen wrote: > Hi All! > > I'm looking at migrating from openldap to freeipa (currently using > 3.3.3 on centos7, installed from the default centos repos, as I'd > prefer to use centos over fedora) and I have a bit of a snag after > importing users with migration-ds: I can't edit the details of > migrated users in the web ui (but I can via `ipa user-mod`). > > Steps to reproduce: > 1. kinit admin > 2. ipa config-mod --enable-migration=TRUE > 3. ipa migrate-ds --base-dn='dc=example,dc=com' > --user-container='ou=People' --group-container='ou=Group' > --bind-dn='cn=admin' --with-compat --schema='RFC2307' > 4. ipa config-mod --enable-migration=FALSE > 5. ipa user-mod test1 --last=LastName1 (success) > 6. visit web ui (logging in as admin), user test1 has "LastName1" as > "last name" field, but no fields on this page are editable. > 7. create new user via web ui "test2". > 8. all fields are editable for user test2. > > Based on the success from step 5, it would appear that the admin user > has the rights to modify test1's details, but the web ui disagrees? > > Thanks! > Steve > > Can you please do an ldap search and get the full entry for one of the migrated users and one for the one of the created users. You might also try --raw flag and use user-show command. I suspect the migrated entries are missing some attribute. If you can help us to identify which one would be great. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Wed Nov 5 20:20:55 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 5 Nov 2014 21:20:55 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> Message-ID: On Wed, Nov 5, 2014 at 7:45 PM, Natxo Asenjo wrote: > And I think I found it: > https://fedorahosted.org/freeipa/ticket/3727 > > > permissions of that folder: > > $ ls -ld publish/ > drwxr-xr-x. 2 root root 73728 Jun 13 2013 publish/ > > I just changed them to pkiuser:pkiuser, let's see what the next run does. and it's fixed (after undoing the change in CS.cfg and re-setting ca.crl.MasterCRL.enableCRLCache=false ca.crl.MasterCRL.enableCRLUpdates=false both to true and reloading pki-cad): -rw-rw-r--. 1 pkiuser pkiuser 1807 Jun 28 2013 MasterCRL-20130628-210000.der -rw-rw-r--. 1 pkiuser pkiuser 5278 Nov 5 21:00 MasterCRL-20141105-210000.der lrwxrwxrwx. 1 pkiuser pkiuser 57 Nov 5 21:00 MasterCRL.bin -> /var/lib/ipa/pki-ca/publish/MasterCRL-20141105-210000.der phew -- Groeten, natxo From william.muriithi at gmail.com Wed Nov 5 20:21:53 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 05 Nov 2014 15:21:53 -0500 Subject: [Freeipa-users] Trust relationship redundancy In-Reply-To: References: Message-ID: <20141105202153.6090901.43141.7604@gmail.com> ?Peter, ?? Sorry, missed your response earlier. On 4.11.2014 21:57, William Muriithi wrote: > Afternoon, > > I have two AD and would like to retain that redundancy within IPA after > establishing trust relationship. How would one achieve that? > > I have attempted the following: > > > [root at ipa3-yyz-int ~]# ipa dnszone-add example.local > --name-server=srvyyzdc02.example.local --name-server=srvyyzdc01.example.local > --admin-email='systemadmin at example.com' --force --forwarder=10.10.10.90 > --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.90 > --ip-address=10.10.10.91 > ipa: ERROR: invalid 'idnssoamname': Only one value is allowed > > And got the following error above > >Hello, >Could you explain what you are trying to achieve, please? Was trying to make sure trust remain in place even if we loose one of the master master AD >What version of FreeIPA do you use? Version 3.3. Default on centos 7 with all updates applied. Not at office at the moment so can't post rpm precise version? >Commands 'ipa dnszone-*' manage DNS and are >not strictly related to AD trusts. >If you add DNS zone to one IPA server it is >automatically served by all other >servers. This applies to master & forward zones >too. Ah. I see. I misunderstood the documentation then. So, would ipa know there are two active directories in the network even without being explicit on the configuration? I am guessing through DNS? If not, what would be needed to clue it of this fact? >To get full redundancy for *master* zones you >have to add all names of IPA DNS >servers to NS records in the zone and also to its >parent zone. (BTW FreeIPA >4.1 will manage in-zone NS records automatically for you.) >For forward zones you don't need to do anything >else. It should just work. -- Petr^2 Spacek Thanks William ------------------------------ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users End of Freeipa-users Digest, Vol 76, Issue 10 ********************************************* From garth.rees at verncon.com Wed Nov 5 20:31:38 2014 From: garth.rees at verncon.com (Garth Rees) Date: Wed, 05 Nov 2014 21:31:38 +0100 Subject: [Freeipa-users] ipa 4.1 on CentOS 7? Any luck? Message-ID: <545A892A.5080608@verncon.com> First post - please be kind to me:-) I got stuck on the same issue, it was the lack of a Jackson-jaxrs-JSON-Provider package. Once I finally got a coherent download for source files for Jackson-jaxrs-JSON-Provider-2.4.3, I have compiled and built a RPM package (using Maven, on Netbeans) which allowed the installation of FreeIPA 4.1.0 onto a Centos 7 machine (7.0.1406) without any problems. It is free to use for anybody, with the usual caveats of absolutely NO GUARANTEES, USE AT YOUR OWN RISK, etc, etc. Contact me at garth{dot}rees{at}verncon{dot}com if you want a copy of it, or is there some way or place on this list it can be loaded into? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Nov 5 20:36:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 22:36:02 +0200 Subject: [Freeipa-users] Trust relationship redundancy In-Reply-To: <20141105202153.6090901.43141.7604@gmail.com> References: <20141105202153.6090901.43141.7604@gmail.com> Message-ID: <20141105203602.GN4107@redhat.com> On Wed, 05 Nov 2014, William Muriithi wrote: >?Peter, >?? >Sorry, missed your response earlier. >On 4.11.2014 21:57, William Muriithi wrote: >> Afternoon, >> >> I have two AD and would like to retain that redundancy within IPA after >> establishing trust relationship. How would one achieve that? >> >> I have attempted the following: >> >> >> [root at ipa3-yyz-int ~]# ipa dnszone-add example.local >> --name-server=srvyyzdc02.example.local --name-server=srvyyzdc01.example.local >> --admin-email='systemadmin at example.com' --force --forwarder=10.10.10.90 >> --forwarder=10.10.10.91 --forward-policy=only --ip-address=10.10.10.90 >> --ip-address=10.10.10.91 >> ipa: ERROR: invalid 'idnssoamname': Only one value is allowed >> >> And got the following error above >> > >>Hello, > >>Could you explain what you are trying to achieve, please? > >Was trying to make sure trust remain in place even if we loose one of the master master AD > >>What version of FreeIPA do you use? > >Version 3.3. Default on centos 7 with all updates applied. Not at office at the moment so can't post rpm precise version? > >>Commands 'ipa dnszone-*' manage DNS and are >not strictly related to AD trusts. >>If you add DNS zone to one IPA server it is >automatically served by all other >>servers. This applies to master & forward zones >too. > >Ah. I see. I misunderstood the documentation then. > >So, would ipa know there are two active directories in the network even >without being explicit on the configuration? I am guessing through DNS? IPA uses DNS SRV records to discover AD DCs to talk to. You can read more about the mechanism Windows uses to discover services via DNS here: http://msdn.microsoft.com/en-us/library/cc717360.aspx If you want redundancy on Active Directory side, make sure DNS zone for Active Directory forest contains SRV records as explained in the MS-ADTS 6.3.6.1 and these records mention all required servers. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Nov 5 20:43:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 22:43:32 +0200 Subject: [Freeipa-users] ATTN: CVE-2014-7828 Message-ID: <20141105204332.GO4107@redhat.com> Hi, Heads up for those who are using 2FA feature of FreeIPA 4.0 and 4.1. A security issue was identified in the released versions of FreeIPA 4.0 and 4.1 that makes possible for users with enabled OTP token to authenticate using only the second factor. We have a fix available already and will be doing releases for 4.0.5 and 4.1.1 tomorrow to get packages into Fedora 21, COPR repos, and Debian Unstable. In meantime, you can mitigate by disabling OTP authentication for the users. Sorry for inconvenience. https://fedorahosted.org/freeipa/ticket/4690 -- / Alexander Bokovoy From technolengy at gmail.com Wed Nov 5 21:21:32 2014 From: technolengy at gmail.com (Steve Nolen) Date: Wed, 5 Nov 2014 13:21:32 -0800 Subject: [Freeipa-users] trouble editing user details after migrating from openldap In-Reply-To: <545A7B81.6060104@redhat.com> References: <545A7B81.6060104@redhat.com> Message-ID: Hi Dmitri! ldapsearch was exactly the pointer I needed! My entries had objectClass=extensibleObject, which, as soon as I removed via: ipa user-mod ldaptest --delattr objectclass=extensibleobject i'm able to edit! Thanks so much for the help! On Wed, Nov 5, 2014 at 11:33 AM, Dmitri Pal wrote: > On 11/05/2014 10:19 AM, Steve Nolen wrote: > > Hi All! > > I'm looking at migrating from openldap to freeipa (currently using 3.3.3 > on centos7, installed from the default centos repos, as I'd prefer to use > centos over fedora) and I have a bit of a snag after importing users with > migration-ds: I can't edit the details of migrated users in the web ui (but > I can via `ipa user-mod`). > > Steps to reproduce: > 1. kinit admin > 2. ipa config-mod --enable-migration=TRUE > 3. ipa migrate-ds --base-dn='dc=example,dc=com' > --user-container='ou=People' --group-container='ou=Group' > --bind-dn='cn=admin' --with-compat --schema='RFC2307' > 4. ipa config-mod --enable-migration=FALSE > 5. ipa user-mod test1 --last=LastName1 (success) > 6. visit web ui (logging in as admin), user test1 has "LastName1" as "last > name" field, but no fields on this page are editable. > 7. create new user via web ui "test2". > 8. all fields are editable for user test2. > > Based on the success from step 5, it would appear that the admin user > has the rights to modify test1's details, but the web ui disagrees? > > Thanks! > Steve > > > Can you please do an ldap search and get the full entry for one of the > migrated users and one for the one of the created users. > You might also try --raw flag and use user-show command. > I suspect the migrated entries are missing some attribute. If you can help > us to identify which one would be great. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Wed Nov 5 22:05:07 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 5 Nov 2014 22:05:07 +0000 Subject: [Freeipa-users] unable to sudo Message-ID: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> First 10 ipa clients I set up - no problem. Set up 2 more, perhaps this is a problem with the fact that these 2 hosts were on a totally new VLAN and the firewall rules weren't correct when I set them up. Been through the part on sudo here... http://www.freeipa.org/page/Troubleshooting nisdomainname is correct on the machines and also in /etc/sysconfig/network had to add 'sudo' to [sssd] services = nss, sudo, pam, ssh and restarted sssd though I don't know why it wasn't added automatically checked nsswitch.conf and netgroup is set to 'files sss' getent netgroup hgroup1 returns nothing on machines where sudo works and doesn't work - can't tell the difference. Added 'sudoers_debug 2' to /etc/sudo_ldap.conf but don't know where that logs And finally, on a machine where ipa users cannot sudo... # sudo -l Matching Defaults entries for root on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User root may run the following commands on this host: (ALL) ALL $ sudo -l [sudo] password for craig.white: Sorry, user craig.white may not run sudo on 599330-stash001. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From tlau at tetrioncapital.com Thu Nov 6 01:11:11 2014 From: tlau at tetrioncapital.com (tlau at tetrioncapital.com) Date: Thu, 06 Nov 2014 09:11:11 +0800 Subject: [Freeipa-users] unable to sudo In-Reply-To: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <20141106011111.5922961.60764.834@tetrioncapital.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: not available URL: From dpal at redhat.com Thu Nov 6 03:34:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Nov 2014 22:34:18 -0500 Subject: [Freeipa-users] unable to sudo In-Reply-To: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <545AEC3A.5070701@redhat.com> On 11/05/2014 05:05 PM, Craig White wrote: > > First 10 ipa clients I set up -- no problem. > > Set up 2 more, perhaps this is a problem with the fact that these 2 > hosts were on a totally new VLAN and the firewall rules weren't > correct when I set them up. > > Been through the part on sudo here... > > http://www.freeipa.org/page/Troubleshooting > > nisdomainname is correct on the machines and also in > /etc/sysconfig/network > > had to add 'sudo' to > > [sssd] > > services = nss, sudo, pam, ssh > > and restarted sssd though I don't know why it wasn't added automatically > > checked nsswitch.conf and netgroup is set to 'files sss' > > getent netgroup hgroup1 > > returns nothing on machines where sudo works and doesn't work -- can't > tell the difference. > > Added 'sudoers_debug 2' to /etc/sudo_ldap.conf but don't know where > that logs > > And finally, on a machine where ipa users cannot sudo... > > # sudo -l > > Matching Defaults entries for root on this host: > > requiretty, !visiblepw, always_set_home, env_reset, > env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", > > env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", > env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", > > env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", > env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > User root may run the following commands on this host: > > (ALL) ALL > > $ sudo -l > > [sudo] password for craig.white: > > Sorry, user craig.white may not run sudo on 599330-stash001. > > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > What is the OS and version of this machine? Rise the debug_level to 7 or higher in SSSD config and send the sanitized logs. The full SSSD config file will also help. BTW it is more a question for the SSSD user list. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From andreas.ladanyi at kit.edu Thu Nov 6 09:24:54 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Thu, 06 Nov 2014 10:24:54 +0100 Subject: [Freeipa-users] Migration Webpage doesnt work Message-ID: <545B3E66.8080804@kit.edu> Hi, i migrated user data with the ipa migrate-ds script without problems. The users in the old OpenLDAP doesnt have a userPasswort and only the kerberos principal from local KRB DB was used for authentification. After migration FreeIPA doesnt have a userPassword and there is no Kerberos hash. Know i tried out the /ipa/migration webpage and want to set a userPassword/Kerberos hash for a user in FreeIPA. The result was the error message i entered the wrong password or/and username. Now my question is what is the requirement for the migration webpage to work ? The documentation says that migration webpage takes a cleartext password and generates the kerberos hash. Does the migration page need a userPassword entry ? I tried out to reset the pssword of a user in the WebUI and the migration webpage works with this password from the manual passwort reset ?! cheers, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5306 bytes Desc: S/MIME Cryptographic Signature URL: From abokovoy at redhat.com Thu Nov 6 09:52:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 11:52:12 +0200 Subject: [Freeipa-users] Migration Webpage doesnt work In-Reply-To: <545B3E66.8080804@kit.edu> References: <545B3E66.8080804@kit.edu> Message-ID: <20141106095212.GU4107@redhat.com> On Thu, 06 Nov 2014, Andreas Ladanyi wrote: >Hi, > >i migrated user data with the ipa migrate-ds script without problems. >The users in the old OpenLDAP doesnt have a userPasswort and only the >kerberos principal from local KRB DB was used for authentification. >After migration FreeIPA doesnt have a userPassword and there is no >Kerberos hash. > >Know i tried out the /ipa/migration webpage and want to set a >userPassword/Kerberos hash for a user in FreeIPA. The result was the >error message i entered the wrong password or/and username. > >Now my question is what is the requirement for the migration webpage to >work ? The documentation says that migration webpage takes a cleartext >password and generates the kerberos hash. Does the migration page need a >userPassword entry ? /ipa/migration page expects that you have a password hash in userPassword attribute set but no Kerberos hashes. It binds to LDAP server using the password user entered on the page and then IPA's plugin performs generation of Kerberos hashes as part of LDAP BIND operation. >I tried out to reset the pssword of a user in the WebUI and the >migration webpage works with this password from the manual passwort reset ?! When you reset the password, all hashes (including Kerberos ones) are generated and then user can change the password either through main login page or the migration page. -- / Alexander Bokovoy From pviktori at redhat.com Thu Nov 6 10:05:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 06 Nov 2014 11:05:48 +0100 Subject: [Freeipa-users] dns stops working after upgrade In-Reply-To: References: <54510035.7010707@redhat.com> <54510424.8080004@redhat.com> <5451205E.8020408@redhat.com> <5458E83B.8040601@redhat.com> <545A28AC.6070700@redhat.com> <545A3737.5000108@redhat.com> <20141105151730.GC3594@origin.bitbin.de> <545A4170.1070109@redhat.com> Message-ID: <545B47FC.4010308@redhat.com> On 11/05/2014 05:22 PM, Rob Verduijn wrote: > I saw in the upstream foreman-prepare-realm script that the new > permission names should include a prefix "System: " > That Prefix is not there, what did change was that some permissions > where no longer lower case only. > ie in 3.3.5 the permission is 'write dns configuration' and in 4.1 it > becomes 'Write DNS Configuration' > > Rob Right. There were some changes to IPA's default policy too, but I don't think it should affect the Foreman proxy very much. For example there are now permissions for reading data, but most are granted to all authenticated users by default. I've left some comments in the pull request. > 2014-11-05 16:25 GMT+01:00 Petr Spacek >: > > On 5.11.2014 16:20, Rob Verduijn wrote: > > Hello, > > Yes I noticed the name change it took me a while to realise it > was a known > ruby bug in katello that caused the real problem. > > I also checked after I updated the 'katello integrated' update > from 3.3.5 > to 4.1 and the permissions were neatly renamed to their new > counterparts. > > However the internal dns no longer worked :( > > > So the permissions broke after upgrade to 4.1, right? pviktori, can > you give us some advice? > > Thanks! > > Petr^2 Spacek > > Rob > > 2014-11-05 16:17 GMT+01:00 Stephen Benjamin >: > > On Wed, Nov 05, 2014 at 09:41:59AM -0500, Rob Crittenden wrote: > > Also when I look at the permissions in ipa there > are no longer any > permissions that have the 'System: ' prefix. > > > AFAIK the foreman proxy is not necessary (and not > supported) with IPA > 4.x because it was obsoleted by 'native' proxy > delivered by Foreman > upstream. > > Am I right, Rob (Crittenden)? :-) > > > I believe he's referring to the native smart proxy here. > It includes a > script to setup permissions. I guess it hasn't been > tested against a 4.x > IPA master. > > > The permissions have changed names in FreeIPA 4.0, which > means the > script won't work. I've tested this one against 4.1 on F21 > and it > works: > > > https://raw.githubusercontent.__com/stbenjam/smart-proxy/8278/__sbin/foreman-prepare-realm > > > There's an open pull request against foreman's Smart Proxy > to include > that in the next release: > > https://github.com/theforeman/__smart-proxy/pull/231-- > > -- Petr? From walter.van.lille at gmail.com Thu Nov 6 13:58:33 2014 From: walter.van.lille at gmail.com (Walter van Lille) Date: Thu, 6 Nov 2014 15:58:33 +0200 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations Message-ID: Hi, I need some assistance please. I've taken over an IPA server to manage a few months ago, and it was working fine until recently when it started acting up seemingly off its own accord. When I do an ipactl status it basically gives an output as shown below: *Directory Service: RUNNING* *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To the tune of 7 minutes sometimes)* *KDC Service: RUNNING* *KPASSWD Service: RUNNING* *DNS Service: RUNNING* *MEMCACHE Service: RUNNING* *HTTP Service: RUNNING* *CA Service: RUNNING* *ADTRUST Service: RUNNING* *EXTID Service: RUNNING* Running top showed that ns-slapd was munching almost all my resources, but I got that fixed by upping the cache. Unfortunately this did not correct the issue and it still reacts in the same fashion, although the resources have been freed up now. I've noticed that when I run dig on either the local server or a remote machine that the query basically just times out as shown here: *dig freeipa.myexample.sample* *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> freeipa.myexample.sample* *;; global options: +cmd* *;; connection timed out; no servers could be reached* When the KDC service fails to start, then name lookups seem OK, but authentication fails. otherwise it's dead in the water. This also happens: *sudo ipactl status* *Directory Service: RUNNING* *Unknown error when retrieving list of services from LDAP:* My software setup is as follows: *CentOS release 6.5 (Final)* *389-ds-base.x86_64 1.2.11.15-34.el6_5* *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-dyndb-ldap.x86_64* *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* *rpcbind.x86_64 0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5* *samba4-winbind.x86_64* *krb5-server.x86_64 1.10.3-15.el6_5.1* *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux* It's not a permanent situation as it sometimes runs 100% for a while, but 80% of the time it is unusable. If anybody can assist me, please be so kind. Regards, Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 6 15:00:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 06 Nov 2014 16:00:21 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: Message-ID: <545B8D05.6030705@redhat.com> On 06/11/14 14:58, Walter van Lille wrote: > Hi, > > I need some assistance please. > I've taken over an IPA server to manage a few months ago, and it was > working fine until recently when it started acting up seemingly off > its own accord. > When I do an ipactl status it basically gives an output as shown below: > > > *Directory Service: RUNNING > * > * > * > *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To > the tune of 7 minutes sometimes)* > * > * > *KDC Service: RUNNING* > *KPASSWD Service: RUNNING* > *DNS Service: RUNNING* > *MEMCACHE Service: RUNNING* > *HTTP Service: RUNNING* > *CA Service: RUNNING* > *ADTRUST Service: RUNNING* > *EXTID Service: RUNNING* > > Running top showed that ns-slapd was munching almost all my resources, > but I got that fixed by upping the cache. Unfortunately this did not > correct the issue and it still reacts in the same fashion, although > the resources have been freed up now. > I've noticed that when I run dig on either the local server or a > remote machine that the query basically just times out as shown here: > > *dig freeipa.myexample.sample* > * > * > *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> > freeipa.myexample.sample* > *;; global options: +cmd* > *;; connection timed out; no servers could be reached* > > When the KDC service fails to start, then name lookups seem OK, but > authentication fails. otherwise it's dead in the water. > > This also happens: > > *sudo ipactl status* > *Directory Service: RUNNING* > *Unknown error when retrieving list of services from LDAP:* > * > * > My software setup is as follows: > > *CentOS release 6.5 (Final) > * > *389-ds-base.x86_64 1.2.11.15-34.el6_5 > * > *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 > * > *bind-dyndb-ldap.x86_64* > *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* > *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* > *rpcbind.x86_64 0.2.0-11.el6 > @anaconda-CentOS-201311291202.x86_64/6.5* > *samba4-winbind.x86_64* > *krb5-server.x86_64 1.10.3-15.el6_5.1 > * > * > * > *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 > x86_64 x86_64 x86_64 GNU/Linux > * > > It's not a permanent situation as it sometimes runs 100% for a while, > but 80% of the time it is unusable. If anybody can assist me, please > be so kind. > > Regards, > > Walter > Hello please which version of bind-dyndb-ldap do you use? I had similar issue with bind-dyndb-ldap, but it was development version, I'm not sure if this is your case. When named was failing, dirserv was really slow. Can you send journalctl -b -u named log when dig doesn't work?? -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 6 15:41:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 Nov 2014 10:41:01 -0500 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <545B8D05.6030705@redhat.com> References: <545B8D05.6030705@redhat.com> Message-ID: <545B968D.20905@redhat.com> On 11/06/2014 10:00 AM, Martin Basti wrote: > On 06/11/14 14:58, Walter van Lille wrote: >> Hi, >> >> I need some assistance please. >> I've taken over an IPA server to manage a few months ago, and it was >> working fine until recently when it started acting up seemingly off >> its own accord. >> When I do an ipactl status it basically gives an output as shown below: >> >> >> *Directory Service: RUNNING >> * >> * >> * >> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To >> the tune of 7 minutes sometimes)* >> * >> * >> *KDC Service: RUNNING* >> *KPASSWD Service: RUNNING* >> *DNS Service: RUNNING* >> *MEMCACHE Service: RUNNING* >> *HTTP Service: RUNNING* >> *CA Service: RUNNING* >> *ADTRUST Service: RUNNING* >> *EXTID Service: RUNNING* >> >> Running top showed that ns-slapd was munching almost all my >> resources, but I got that fixed by upping the cache. Unfortunately >> this did not correct the issue and it still reacts in the same >> fashion, although the resources have been freed up now. >> I've noticed that when I run dig on either the local server or a >> remote machine that the query basically just times out as shown here: >> >> *dig freeipa.myexample.sample* >> * >> * >> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >> freeipa.myexample.sample* >> *;; global options: +cmd* >> *;; connection timed out; no servers could be reached* >> >> When the KDC service fails to start, then name lookups seem OK, but >> authentication fails. otherwise it's dead in the water. >> >> This also happens: >> >> *sudo ipactl status* >> *Directory Service: RUNNING* >> *Unknown error when retrieving list of services from LDAP:* >> * >> * >> My software setup is as follows: >> >> *CentOS release 6.5 (Final) >> * >> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >> * >> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >> * >> *bind-dyndb-ldap.x86_64* >> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *rpcbind.x86_64 0.2.0-11.el6 >> @anaconda-CentOS-201311291202.x86_64/6.5* >> *samba4-winbind.x86_64* >> *krb5-server.x86_64 1.10.3-15.el6_5.1 >> * >> * >> * >> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 >> x86_64 x86_64 x86_64 GNU/Linux >> * >> >> It's not a permanent situation as it sometimes runs 100% for a while, >> but 80% of the time it is unusable. If anybody can assist me, please >> be so kind. >> >> Regards, >> >> Walter >> > Hello please which version of bind-dyndb-ldap do you use? > I had similar issue with bind-dyndb-ldap, but it was development > version, I'm not sure if this is your case. > When named was failing, dirserv was really slow. > > Can you send journalctl -b -u named log when dig doesn't work?? > > -- > Martin Basti > > You also want to look at the directory server logs especially at startup and see what is it doing. Also check the diskspace. May be you do not have much room on the volume and it might cause DS to slow down. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Thu Nov 6 15:42:25 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Thu, 6 Nov 2014 15:42:25 +0000 Subject: [Freeipa-users] unable to sudo In-Reply-To: <20141106011111.5922961.60764.834@tetrioncapital.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> <20141106011111.5922961.60764.834@tetrioncapital.com> Message-ID: As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but ? once I did so, it pointed out that the Rackspace RHEL packaging that doesn?t provide what I need ? possibly need from epel. # yum search /usr/lib64/libsss_sudo.so Loaded plugins: rhnplugin, security This system is receiving updates from RHN Classic or RHN Satellite. rackspace | 1.3 kB 00:00 rackspace-rhel-x86_64-server-6.5.z-common | 871 B 00:00 rackspace-rhel-x86_64-server-6.5.z-ius | 871 B 00:00 rhel-x86_64-server-6.5.z | 1.5 kB 00:00 rhel-x86_64-server-optional-6.5.z | 1.5 kB 00:00 rhn-tools-rhel-x86_64-server-6.5.z | 1.3 kB 00:00 vmware-tools | 951 B 00:00 Warning: No matches found for: /usr/lib64/libsss_sudo.so No Matches found Blockage identified, solution being searched Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 From: tlau at tetrioncapital.com [mailto:tlau at tetrioncapital.com] Sent: Wednesday, November 05, 2014 6:11 PM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] unable to sudo Hi, Did you config HBAC to allow sudo, then in sudo rules, allow your sudo command, next would be adding HBAC rules to user group?? Sent from my BlackBerry 10 smartphone. From: Craig White Sent: Thursday, 6 November, 2014 6:11 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] unable to sudo First 10 ipa clients I set up ? no problem. Set up 2 more, perhaps this is a problem with the fact that these 2 hosts were on a totally new VLAN and the firewall rules weren?t correct when I set them up. Been through the part on sudo here? http://www.freeipa.org/page/Troubleshooting nisdomainname is correct on the machines and also in /etc/sysconfig/network had to add ?sudo? to [sssd] services = nss, sudo, pam, ssh and restarted sssd though I don?t know why it wasn?t added automatically checked nsswitch.conf and netgroup is set to ?files sss? getent netgroup hgroup1 returns nothing on machines where sudo works and doesn?t work ? can?t tell the difference. Added ?sudoers_debug 2? to /etc/sudo_ldap.conf but don?t know where that logs And finally, on a machine where ipa users cannot sudo? # sudo -l Matching Defaults entries for root on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User root may run the following commands on this host: (ALL) ALL $ sudo -l [sudo] password for craig.white: Sorry, user craig.white may not run sudo on 599330-stash001. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From lslebodn at redhat.com Thu Nov 6 16:33:50 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 6 Nov 2014 17:33:50 +0100 Subject: [Freeipa-users] unable to sudo In-Reply-To: References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> <20141106011111.5922961.60764.834@tetrioncapital.com> Message-ID: <20141106163350.GB31611@mail.corp.redhat.com> On (06/11/14 15:42), Craig White wrote: >As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but ? once I did so, it pointed out that the Rackspace RHEL packaging that doesn?t provide what I need ? possibly need from epel. > ># yum search /usr/lib64/libsss_sudo.so This file was in separate package in sssd 1.9. The packaging was changed in sssd >= 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 >Loaded plugins: rhnplugin, security >This system is receiving updates from RHN Classic or RHN Satellite. >rackspace | 1.3 kB 00:00 >rackspace-rhel-x86_64-server-6.5.z-common | 871 B 00:00 >rackspace-rhel-x86_64-server-6.5.z-ius | 871 B 00:00 >rhel-x86_64-server-6.5.z | 1.5 kB 00:00 >rhel-x86_64-server-optional-6.5.z | 1.5 kB 00:00 >rhn-tools-rhel-x86_64-server-6.5.z | 1.3 kB 00:00 >vmware-tools | 951 B 00:00 >Warning: No matches found for: /usr/lib64/libsss_sudo.so >No Matches found > >Blockage identified, solution being searched > >Craig White >System Administrator >O 623-201-8179 M 602-377-9752 > LS From pvoborni at redhat.com Thu Nov 6 16:34:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 17:34:41 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.0.5 Message-ID: <545BA321.7020906@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.5 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 21 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/ COPR repository]. == Highlights in 4.0.5 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * prevent possible deadlocks with schema compatibility plugin == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.4 == === Martin Basti (1) === * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Vobornik (1) === * Become IPA 4.0.5 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik From rob.verduijn at gmail.com Thu Nov 6 16:27:07 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 6 Nov 2014 17:27:07 +0100 Subject: [Freeipa-users] missing package in 4.1.1 repo Message-ID: Hi, There is a dependency error in the updated repo. I did a yum clean all then a yum update. I got this error: Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) Requires: slapi-nis >= 0.54.1-1 Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) slapi-nis = 0.52-1.fc20 Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) slapi-nis = 0.54-1.fc20 Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) slapi-nis = 0.50-1.fc20 yum list --show-duplicates slapi-nis Installed Packages slapi-nis.x86_64 0.54-1.fc20 @mkosek-freeipa Available Packages slapi-nis.x86_64 0.50-1.fc20 private.base slapi-nis.x86_64 0.52-1.fc20 private.updates slapi-nis.x86_64 0.54-1.fc20 mkosek-freeipa there is no 0.54.1-1.fc20 version of slapi-nis Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Nov 6 16:35:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 17:35:27 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.1.1 Message-ID: <545BA34F.2060100@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.1 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.1 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * various bug fixes in CA management tools and DNS sec * Allow reading SSH public keys overrides of users * Allow reading GID value override for users * prevent possible deadlocks with schema compatibility plugin == Known Issues == * On Fedora 21 beta, FreeIPA server installation fails with SELinux in enforcing mode. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.1.0 == === Alexander Bokovoy (1) === * Add ipaSshPubkey and gidNumber to the ACI to read ID user overrides === David Kupka (2) === * Respect UID and GID soft static allocation. * Stop dirsrv last in ipactl stop. === Jan Cholasta (10) === * Do not check if port 8443 is available in step 2 of external CA install * Handle profile changes in dogtag-ipa-ca-renew-agent * Do not wait for new CA certificate to appear in LDAP in ipa-certupdate * Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage * Fix possible NULL dereference in ipa-kdb * Fix memory leaks in ipa-extdom-extop * Fix various bugs in ipa-opt-counter and ipa-otp-lasttoken * Fix memory leak in ipa-pwd-extop * Fix memory leaks in ipa-join * Fix various bugs in ipap11helper === Martin Basti (4) === * Fix dns zonemgr validation regression * Add bind-dyndb-ldap working dir to IPA specfile * Fix CI tests: install_adtrust * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Spacek (1) === * Fix zone name to directory name conversion in BINDMgr. === Petr Vobornik (2) === * build: increase java stack size for all arches * Become IPA 4.1.1 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik From abokovoy at redhat.com Thu Nov 6 16:47:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 18:47:01 +0200 Subject: [Freeipa-users] missing package in 4.1.1 repo In-Reply-To: References: Message-ID: <20141106164701.GY4107@redhat.com> On Thu, 06 Nov 2014, Rob Verduijn wrote: >Hi, > >There is a dependency error in the updated repo. >I did a yum clean all >then a yum update. > >I got this error: >Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) > Requires: slapi-nis >= 0.54.1-1 > Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) > slapi-nis = 0.52-1.fc20 > Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) > slapi-nis = 0.54-1.fc20 > Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) > slapi-nis = 0.50-1.fc20 > > >yum list --show-duplicates slapi-nis >Installed Packages >slapi-nis.x86_64 0.54-1.fc20 > @mkosek-freeipa >Available Packages >slapi-nis.x86_64 0.50-1.fc20 > private.base >slapi-nis.x86_64 0.52-1.fc20 > private.updates >slapi-nis.x86_64 0.54-1.fc20 > mkosek-freeipa > >there is no 0.54.1-1.fc20 version of slapi-nis It is being rebuilt as we speak. https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ -- / Alexander Bokovoy From abokovoy at redhat.com Thu Nov 6 16:56:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 18:56:14 +0200 Subject: [Freeipa-users] missing package in 4.1.1 repo In-Reply-To: <20141106164701.GY4107@redhat.com> References: <20141106164701.GY4107@redhat.com> Message-ID: <20141106165614.GZ4107@redhat.com> On Thu, 06 Nov 2014, Alexander Bokovoy wrote: >On Thu, 06 Nov 2014, Rob Verduijn wrote: >>Hi, >> >>There is a dependency error in the updated repo. >>I did a yum clean all >>then a yum update. >> >>I got this error: >>Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) >> Requires: slapi-nis >= 0.54.1-1 >> Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) >> slapi-nis = 0.52-1.fc20 >> Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) >> slapi-nis = 0.54-1.fc20 >> Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) >> slapi-nis = 0.50-1.fc20 >> >> >>yum list --show-duplicates slapi-nis >>Installed Packages >>slapi-nis.x86_64 0.54-1.fc20 >> @mkosek-freeipa >>Available Packages >>slapi-nis.x86_64 0.50-1.fc20 >> private.base >>slapi-nis.x86_64 0.52-1.fc20 >> private.updates >>slapi-nis.x86_64 0.54-1.fc20 >> mkosek-freeipa >> >>there is no 0.54.1-1.fc20 version of slapi-nis >It is being rebuilt as we speak. >https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ Done and should be available. -- / Alexander Bokovoy From jkinney at emory.edu Thu Nov 6 17:04:52 2014 From: jkinney at emory.edu (Jim Kinney) Date: Thu, 06 Nov 2014 12:04:52 -0500 Subject: [Freeipa-users] Question about oVirt In-Reply-To: <5459340A.8000704@redhat.com> References: <54591AA9.9000906@redhat.com> <5459340A.8000704@redhat.com> Message-ID: <1415293492.13384.32.camel@serenity.cci.emory.edu> On Tue, 2014-11-04 at 15:16 -0500, Dmitri Pal wrote: > On 11/04/2014 01:27 PM, Dmitri Pal wrote: > > > Hello Jim, > > > > I am re-posting your question to the FreeIPA list as it belongs > > there. > > > > Here is the copy of the original question. > > > > Subject: > > [ovirt-users] templates and freeipa > > From: > > Jim Kinney > > Date: > > 10/31/2014 02:55 PM > > To: > > "users at ovirt.org" > > > > Ovirt 3.5 is running well for me and I have freeIPA controlling > > access to the user portal. I would like to provide templates of > > various linux setups that all have freeipa for user authentication > > in the VM for my developers to be able to create a new VM from and > > then log in using their freeIPA access and sudo control. I'm wanting > > to group developers by project and use freeIPA to set sudo commands > > as needed (group A get oracle, group B get postgresql, etc). Wanting > > to maximize developer ability while minimizing my clean up time :-) > > They will be able to delete VMs they create. > > > > > > It's possible to do a kickstart deploy with freeIPA registration but > > a template from that will be a problem as it will have the same keys > > for all VMs. > > > > > > Is there a post-creation scripting process I can attach to in ovirt > > or should I look at a default root user and script that > > personalizes the new VM? > > > > -- > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > Which provisioning technique you are using? > Would something like what Adam describes here [1] or Foreman uses here > [2] would be relevant? > > [1] http://adam.younglogic.com/2013/09/register-vm-freeipa/ > [2] http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. I'm currently using a pre-built template that the devs have access to clone from. The scripted process from Adam Young is what I'm looking at now. I've not grokked enough of Foreman yet to begin a test implementation. It looks to be more capable (the remove DNS entry on delete is a key thing) and will likely be the direction I go. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkinney at emory.edu 404.712.0300 bmi.emory.edu From CWhite at skytouchtechnology.com Thu Nov 6 19:27:04 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Thu, 6 Nov 2014 19:27:04 +0000 Subject: [Freeipa-users] unable to sudo In-Reply-To: <20141106163350.GB31611@mail.corp.redhat.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> <20141106011111.5922961.60764.834@tetrioncapital.com> <20141106163350.GB31611@mail.corp.redhat.com> Message-ID: <8a59418a5c6846949a52980386fc90b9@BLUPR08MB488.namprd08.prod.outlook.com> -----Original Message----- From: Lukas Slebodnik [mailto:lslebodn at redhat.com] Sent: Thursday, November 06, 2014 9:34 AM To: Craig White Cc: tlau at tetrioncapital.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] unable to sudo On (06/11/14 15:42), Craig White wrote: >As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but ? once I did so, it pointed out that the Rackspace RHEL packaging that doesn?t provide what I need ? possibly need from epel. > ># yum search /usr/lib64/libsss_sudo.so This file was in separate package in sssd 1.9. The packaging was changed in sssd >= 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 ---- Unfortunately for me, Rackspace still has these boxes on RHEL 6.5 # rpm -qa | grep sssd sssd-client-1.9.2-129.el6_5.4.x86_64 sssd-1.9.2-129.el6_5.4.x86_64 nowhere to go I think - thanks From tlau at athenacr.com Fri Nov 7 01:20:35 2014 From: tlau at athenacr.com (Thomas Lau) Date: Fri, 07 Nov 2014 09:20:35 +0800 Subject: [Freeipa-users] Kerberos for cronjoob Message-ID: <-4236057863862732439@unknownmsgid> ?Hi, Is it possible to renew ticket once in a while for cronjob to run on certain users? How do you guys run cronjob on Kerberos user without getting ticket expire? Sent from my BlackBerry 10 smartphone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 7 03:28:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 Nov 2014 22:28:34 -0500 Subject: [Freeipa-users] Kerberos for cronjoob In-Reply-To: <-4236057863862732439@unknownmsgid> References: <-4236057863862732439@unknownmsgid> Message-ID: <545C3C62.8020801@redhat.com> On 11/06/2014 08:20 PM, Thomas Lau wrote: > ?Hi, > > Is it possible to renew ticket once in a while for cronjob to run on > certain users? How do you guys run cronjob on Kerberos user without > getting ticket expire? > > Sent from my BlackBerry 10 smartphone. > > Here is an example: http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/ But starting kerberos 1.11 kerberos library should be able to automatically renew the ticket for service accounts http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Fri Nov 7 05:00:04 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 6 Nov 2014 21:00:04 -0800 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <20141105090507.GZ14368@hendrix.brq.redhat.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> Message-ID: I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: auth required pam_env.so auth sufficient pam_sss.so auth required pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek wrote: > On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > > Thanks for the reply. The PAM file is pretty stock for a centos build > > > > #%PAM-1.0 > > # This file is auto-generated. > > # User changes will be destroyed the next time authconfig is run. > > auth required pam_env.so > > auth sufficient pam_unix.so nullok try_first_pass > > auth requisite pam_succeed_if.so uid >= 500 quiet > > auth sufficient pam_sss.so use_first_pass > > auth required pam_deny.so > > > > account required pam_unix.so > > account sufficient pam_localuser.so > > account sufficient pam_succeed_if.so uid < 500 quiet > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > account required pam_permit.so > > > > password requisite pam_cracklib.so try_first_pass retry=3 type= > > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok > > password sufficient pam_sss.so use_authtok > > password required pam_deny.so > > > > session optional pam_keyinit.so revoke > > session required pam_limits.so > > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > > session required pam_unix.so > > session optional pam_sss.so > > > > > > Best regards > > David Taylor > > OK, so pam_sss is there ... > > And yet you see no mention of pam_sss.so in /var/log/secure ? > > Is this the file that was included from the service-specific PAM > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Nov 7 05:18:30 2014 From: mail at willsheldon.com (Will Sheldon) Date: Thu, 6 Nov 2014 21:18:30 -0800 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade Message-ID: Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we?ve had a great 12-18 months hassle free use out of it ?- it is a fantastically stable trouble free solution? however now we?ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It?s likely not an IPA issue, it also reset it?s hostname somehow after the upgrade (it?s an image in an openstack environment)? If anyone has any pointers as to how to debug I?d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com? Server1 can?t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. and the servers: [root at server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica ? last init status: None ? last init ended: None ? last update status: 0 Replica acquired successfully: Incremental update started ? last update ended: 2014-11-07 01:35:58+00:00 [root at server1 ~]# [root at server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica ? last init status: None ? last init ended: None ? last update status: 0 Replica acquired successfully: Incremental update succeeded ? last update ended: 2014-11-07 01:35:43+00:00 [root at server2 ~]# ? Will Sheldon -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.taylor at speedcast.com Fri Nov 7 05:26:32 2014 From: david.taylor at speedcast.com (David Taylor) Date: Fri, 7 Nov 2014 05:26:32 +0000 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> Message-ID: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> As an add on, I?ve upgraded our Xen template to 6.6 and run up a new VM using that and it attaches to the IPA environment perfectly well, so I?m guessing it is an issue with the upgrade scripts. Best regards David Taylor From: Michael Lasevich [mailto:mlasevich at gmail.com] Sent: Friday, 7 November 2014 4:00 PM To: Jakub Hrozek Cc: David Taylor; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 (centos 6.5 to 6.6) I seem to be able to log in via ssh, but when I use http pam service, I get inconsistent behavior - seems like sometimes it works and others it errors out (success and failure can happen within a second) In the logs I see things like: [sssd[krb5_child[15410]]]: Internal credentials cache error and authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=username received for user username: 4 (System error) Nothing in the audit.log that I can see I am guessing this is an sssd issue but I am hoping someone here knows how to deal with it. IN case it matters - here is the pam config: auth required pam_env.so auth sufficient pam_sss.so auth required pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so -M On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek > wrote: On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > Thanks for the reply. The PAM file is pretty stock for a centos build > > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > > Best regards > David Taylor OK, so pam_sss is there ... And yet you see no mention of pam_sss.so in /var/log/secure ? Is this the file that was included from the service-specific PAM 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Fri Nov 7 05:33:35 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 6 Nov 2014 21:33:35 -0800 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> Message-ID: For what its worth, my issue was resolved when I rebooted the server. Restarting sssd and/or clearing it's cache did not do it, but a full reboot seems to have done it. Something much have been cached or some temp file I missed. Will need to look into it further as I have a number of servers yet to be upgraded and having to reboot linux servers to do an upgrade seem sacrilegious... -M On Thu, Nov 6, 2014 at 9:26 PM, David Taylor wrote: > As an add on, I?ve upgraded our Xen template to 6.6 and run up a new VM > using that and it attaches to the IPA environment perfectly well, so I?m > guessing it is an issue with the upgrade scripts. > > > > > > Best regards > > *David Taylor* > > *From:* Michael Lasevich [mailto:mlasevich at gmail.com] > *Sent:* Friday, 7 November 2014 4:00 PM > *To:* Jakub Hrozek > *Cc:* David Taylor; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to > 6.6 > > > > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 > (centos 6.5 to 6.6) > > > > I seem to be able to log in via ssh, but when I use http pam service, I > get inconsistent behavior - seems like sometimes it works and others it > errors out (success and failure can happen within a second) > > > > In the logs I see things like: > > > > [sssd[krb5_child[15410]]]: Internal credentials cache error > > and > > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= > user=username > received for user username: 4 (System error) > > Nothing in the audit.log that I can see > > I am guessing this is an sssd issue but I am hoping someone here knows how > to deal with it. > > IN case it matters - here is the pam config: > > auth required pam_env.so > auth sufficient pam_sss.so > auth required pam_deny.so > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > > > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session optional pam_sss.so > > -M > > > > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek wrote: > > On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > > Thanks for the reply. The PAM file is pretty stock for a centos build > > > > #%PAM-1.0 > > # This file is auto-generated. > > # User changes will be destroyed the next time authconfig is run. > > auth required pam_env.so > > auth sufficient pam_unix.so nullok try_first_pass > > auth requisite pam_succeed_if.so uid >= 500 quiet > > auth sufficient pam_sss.so use_first_pass > > auth required pam_deny.so > > > > account required pam_unix.so > > account sufficient pam_localuser.so > > account sufficient pam_succeed_if.so uid < 500 quiet > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > account required pam_permit.so > > > > password requisite pam_cracklib.so try_first_pass retry=3 type= > > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok > > password sufficient pam_sss.so use_authtok > > password required pam_deny.so > > > > session optional pam_keyinit.so revoke > > session required pam_limits.so > > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > > session required pam_unix.so > > session optional pam_sss.so > > > > > > Best regards > > David Taylor > > OK, so pam_sss is there ... > > And yet you see no mention of pam_sss.so in /var/log/secure ? > > Is this the file that was included from the service-specific PAM > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 7 06:01:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Nov 2014 01:01:15 -0500 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: Message-ID: <545C602B.90802@redhat.com> On 11/07/2014 12:18 AM, Will Sheldon wrote: > > Hello all :) > > On the whole we are loving FreeIPA, Many thanks and much respect to > all involved, we've had a great 12-18 months hassle free use out of it > - it is a fantastically stable trouble free solution... however now > we've run into a small issue we (as mere mortals) are finding it hard > to resolve :-/ > > We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems > to go well, but one server is behaving oddly. It's likely not an IPA > issue, it also reset it's hostname somehow after the upgrade (it's an > image in an openstack environment) > > If anyone has any pointers as to how to debug I'd be hugely > appreciative :) > > Two servers, server1.domain.com and server2.domain.com > > Server1 can't push data to server2, there are updates and new records > on server1 that do not exist on server2. > > > from the logs on server1: > > [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - > agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to > send endReplication extended operation (Can't contact LDAP server) > [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - > agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with > GSSAPI auth resumed > [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - > agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to > replicate schema: rc=2 > [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - > agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to > replay change (uniqueid (null), CSN (null)): Can't contact LDAP > server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. > > > and the servers: > > [root at server1 ~]# ipa-replica-manage list -v `hostname` > Directory Manager password: > > server2.domain.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update started > last update ended: 2014-11-07 01:35:58+00:00 > [root at server1 ~]# > > > > [root at server2 ~]# ipa-replica-manage list -v `hostname` > Directory Manager password: > > server1.domain.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-11-07 01:35:43+00:00 > [root at server2 ~]# > > > > > Will Sheldon > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Nov 7 06:24:50 2014 From: mail at willsheldon.com (Will Sheldon) Date: Thu, 6 Nov 2014 22:24:50 -0800 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <545C602B.90802@redhat.com> References: <545C602B.90802@redhat.com> Message-ID: On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com) wrote: On 11/07/2014 12:18 AM, Will Sheldon wrote: Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we?ve had a great 12-18 months hassle free use out of it ?- it is a fantastically stable trouble free solution? however now we?ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It?s likely not an IPA issue, it also reset it?s hostname somehow after the upgrade (it?s an image in an openstack environment)? If anyone has any pointers as to how to debug I?d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com? Server1 can?t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running All seems working: [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at server1 ~]# And: [root at server2 ~]# /etc/init.d/dirsrv status dirsrv DOMAIN-COM (pid 1009) is running... dirsrv PKI-IPA (pid 1083) is running... [root at server2 ~]# ? Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root at server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica ? last init status: None ? last init ended: None ? last update status: 0 Replica acquired successfully: Incremental update started ? last update ended: 2014-11-07 01:35:58+00:00 [root at server1 ~]# [root at server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica ? last init status: None ? last init ended: None ? last update status: 0 Replica acquired successfully: Incremental update succeeded ? last update ended: 2014-11-07 01:35:43+00:00 [root at server2 ~]# ? Will Sheldon -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. --? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Nov 7 07:04:41 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 7 Nov 2014 08:04:41 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> Message-ID: <20141107070440.GA22950@mail.corp.redhat.com> On (06/11/14 21:00), Michael Lasevich wrote: >I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 >(centos 6.5 to 6.6) > >I seem to be able to log in via ssh, but when I use http pam service, I get >inconsistent behavior - seems like sometimes it works and others it errors >out (success and failure can happen within a second) > >In the logs I see things like: > >[sssd[krb5_child[15410]]]: Internal credentials cache error > >and > >authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= >user=username >received for user username: 4 (System error) When pam_sss returned "System error" it meand unextected situation in sssd. If you are able to reproduce problem on another machine (youhave alredy restarted this one) could you provide log files from sssd? put "debug_level = 7" into doman section of /etc/sssd/sssd.conf and log files will be stored in directory /var/log/sssd/ LS From pspacek at redhat.com Fri Nov 7 08:17:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 09:17:03 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <545B968D.20905@redhat.com> References: <545B8D05.6030705@redhat.com> <545B968D.20905@redhat.com> Message-ID: <545C7FFF.3050905@redhat.com> On 6.11.2014 16:41, Dmitri Pal wrote: > On 11/06/2014 10:00 AM, Martin Basti wrote: >> On 06/11/14 14:58, Walter van Lille wrote: >>> Hi, >>> >>> I need some assistance please. >>> I've taken over an IPA server to manage a few months ago, and it was >>> working fine until recently when it started acting up seemingly off its own >>> accord. >>> When I do an ipactl status it basically gives an output as shown below: >>> >>> >>> *Directory Service: RUNNING >>> * >>> * >>> * >>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To the >>> tune of 7 minutes sometimes)* >>> * >>> * >>> *KDC Service: RUNNING* >>> *KPASSWD Service: RUNNING* >>> *DNS Service: RUNNING* >>> *MEMCACHE Service: RUNNING* >>> *HTTP Service: RUNNING* >>> *CA Service: RUNNING* >>> *ADTRUST Service: RUNNING* >>> *EXTID Service: RUNNING* >>> >>> Running top showed that ns-slapd was munching almost all my resources, but >>> I got that fixed by upping the cache. Unfortunately this did not correct >>> the issue and it still reacts in the same fashion, although the resources >>> have been freed up now. >>> I've noticed that when I run dig on either the local server or a remote >>> machine that the query basically just times out as shown here: >>> >>> *dig freeipa.myexample.sample* >>> * >>> * >>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>> freeipa.myexample.sample* >>> *;; global options: +cmd* >>> *;; connection timed out; no servers could be reached* >>> >>> When the KDC service fails to start, then name lookups seem OK, but >>> authentication fails. otherwise it's dead in the water. >>> >>> This also happens: >>> >>> *sudo ipactl status* >>> *Directory Service: RUNNING* >>> *Unknown error when retrieving list of services from LDAP:* >>> * >>> * >>> My software setup is as follows: >>> >>> *CentOS release 6.5 (Final) >>> * >>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>> * >>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>> * >>> *bind-dyndb-ldap.x86_64* >>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *rpcbind.x86_64 0.2.0-11.el6 @anaconda-CentOS-201311291202.x86_64/6.5* >>> *samba4-winbind.x86_64* >>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>> * >>> * >>> * >>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 x86_64 >>> x86_64 x86_64 GNU/Linux >>> * >>> >>> It's not a permanent situation as it sometimes runs 100% for a while, but >>> 80% of the time it is unusable. If anybody can assist me, please be so kind. >>> >>> Regards, >>> >>> Walter >>> >> Hello please which version of bind-dyndb-ldap do you use? >> I had similar issue with bind-dyndb-ldap, but it was development version, >> I'm not sure if this is your case. >> When named was failing, dirserv was really slow. >> >> Can you send journalctl -b -u named log when dig doesn't work?? >> >> -- >> Martin Basti >> >> > You also want to look at the directory server logs especially at startup and > see what is it doing. > Also check the diskspace. May be you do not have much room on the volume and > it might cause DS to slow down. One thing to keep in mind: FreeIPA DNS service is backed by LDAP so can't possibly work if your LDAP server is down or is unresponsive. If you encounter a problem with DNS again please try to follow steps 1-5 described on page https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart . I'm mainly interested in results obtained in step 5 (other steps are just prerequisite). It will tell us if DNS (bind-dyndb-ldap) is broken or if LDAP server does not respond and DNS is failing because of the cascade/domino effect. Good luck! -- Petr^2 Spacek From sbose at redhat.com Fri Nov 7 08:41:06 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 7 Nov 2014 09:41:06 +0100 Subject: [Freeipa-users] Kerberos for cronjoob In-Reply-To: <545C3C62.8020801@redhat.com> References: <-4236057863862732439@unknownmsgid> <545C3C62.8020801@redhat.com> Message-ID: <20141107084106.GB26747@localhost.localdomain> On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote: > On 11/06/2014 08:20 PM, Thomas Lau wrote: > >?Hi, > > > >Is it possible to renew ticket once in a while for cronjob to run on > >certain users? How do you guys run cronjob on Kerberos user without > >getting ticket expire? > > > >Sent from my BlackBerry 10 smartphone. > > > > > Here is an example: http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/ > > But starting kerberos 1.11 kerberos library should be able to automatically > renew the ticket for service accounts > http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation SSSD can renew tickets as well, see krb5_renew_interval option described in sssd-krb5(5). Depending on how often your cronjob is run and what is the lifetime of your tickets you might just call 'kinit -R' at the beginning of the cronjob. bye, Sumit > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 From mbasti at redhat.com Fri Nov 7 08:52:32 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 09:52:32 +0100 Subject: [Freeipa-users] Fwd: Re: dns stops working after upgrade In-Reply-To: References: Message-ID: <545C8850.4000401@redhat.com> Forward message back to list -------- Original Message -------- Subject: Re: [Freeipa-users] dns stops working after upgrade Date: Thu, 6 Nov 2014 21:42:55 +0100 From: Rob Verduijn To: Martin Basti Hi again, I tried the update to 4.1.1 It didn't went well, actually it went worse than to 4.1. Now the directory service went down and was no longer able to start. Some part of the logs is below. Besides the warnings about a weak cipher there was not much in the journalctl. It's getting late overhere, I'll dig into the logs tomorrow. Rob Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory Server TJAKO-THUIS.... Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory Server TJAKO-THUIS.. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_3des_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza is not available in NSS 3.17. Ignoring fortezza Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring fortezza_rc4_128_sha Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_null is not available in NSS 3.17. Ignoring fortezza_null Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled since allowWeakCipher is "on" (default setting for the backward compatibility). We strongly recommend to set it to "off". Please replace the value of allowWeakCipher with "off" in the encryption config entry cn=encryption,cn=config and restart the server. Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: dirsrv at TJAKO-THUIS.service: main process exited, code=exited, status=1/FAILURE Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit dirsrv at TJAKO-THUIS.service entered failed state. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlau at tetrioncapital.com Fri Nov 7 09:10:22 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Fri, 7 Nov 2014 17:10:22 +0800 Subject: [Freeipa-users] Kerberos for cronjoob In-Reply-To: <20141107084106.GB26747@localhost.localdomain> References: <-4236057863862732439@unknownmsgid> <545C3C62.8020801@redhat.com> <20141107084106.GB26747@localhost.localdomain> Message-ID: Hi, ?Thanks for replying. I am running Ubuntu 14 IPA client, here is the result when I try to run kinit -R tlau at mocha:~$ kinit -R kinit: KDC can't fulfill requested option while renewing credentials tlau at mocha:~$ klist Ticket cache: FILE:/tmp/krb5cc_1218400003_rZ7eX7 Default principal: tlau at DOMAIN.COM Valid starting Expires Service principal 2014-11-07T16:59:42 2014-11-08T16:59:42 krbtgt/DOMAIN.COM at DOMAIN.COM tlau at mocha:~$ date Fri Nov 7 17:09:24 HKT 2014? Any idea why? On Fri, Nov 7, 2014 at 4:41 PM, Sumit Bose wrote: > On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote: > > On 11/06/2014 08:20 PM, Thomas Lau wrote: > > >?Hi, > > > > > >Is it possible to renew ticket once in a while for cronjob to run on > > >certain users? How do you guys run cronjob on Kerberos user without > > >getting ticket expire? > > > > > >Sent from my BlackBerry 10 smartphone. > > > > > > > > Here is an example: > http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/ > > > > But starting kerberos 1.11 kerberos library should be able to > automatically > > renew the ticket for service accounts > > http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation > > SSSD can renew tickets as well, see krb5_renew_interval option described > in sssd-krb5(5). > > Depending on how often your cronjob is run and what is the lifetime of > your tickets you might just call 'kinit -R' at the beginning of the > cronjob. > > bye, > Sumit > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > -- > > 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 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Nov 7 09:17:41 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Nov 2014 11:17:41 +0200 Subject: [Freeipa-users] Kerberos for cronjoob In-Reply-To: <20141107084106.GB26747@localhost.localdomain> References: <-4236057863862732439@unknownmsgid> <545C3C62.8020801@redhat.com> <20141107084106.GB26747@localhost.localdomain> Message-ID: <20141107091741.GB4107@redhat.com> On Fri, 07 Nov 2014, Sumit Bose wrote: >On Thu, Nov 06, 2014 at 10:28:34PM -0500, Dmitri Pal wrote: >> On 11/06/2014 08:20 PM, Thomas Lau wrote: >> >?Hi, >> > >> >Is it possible to renew ticket once in a while for cronjob to run on >> >certain users? How do you guys run cronjob on Kerberos user without >> >getting ticket expire? >> > >> >Sent from my BlackBerry 10 smartphone. >> > >> > >> Here is an example: http://adam.younglogic.com/2013/05/kerberizing-postgresql-with-freeipa-for-keystone/ >> >> But starting kerberos 1.11 kerberos library should be able to automatically >> renew the ticket for service accounts >> http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation > >SSSD can renew tickets as well, see krb5_renew_interval option described >in sssd-krb5(5). > >Depending on how often your cronjob is run and what is the lifetime of >your tickets you might just call 'kinit -R' at the beginning of the >cronjob. Note that it will only work if your KDC allows to issue renewable tickets. FreeIPA by default does allow it but you have to explicitly ask for renewable time longer than the ticket validity time: $ kinit -r 15h -l 10h admin Password for admin at IPACLOUD.TEST: $ klist -edf Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin at IPACLOUD.TEST Valid starting Expires Service principal 07.11.2014 11:10:56 07.11.2014 21:10:53 krbtgt/IPACLOUD.TEST at IPACLOUD.TEST renew until 08.11.2014 02:10:53, Flags: FRIA Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 as can be seen above, I've asked for 15h of renewal time while ticket lifetime is 10h. I'm getting back a TGT that has R flag set (renewable) and that can be renewed 5h beyond the expiration time. Not that 5 hours are helpful here because if ticket is expired, it cannot be renewed anymore even it the R flag is there but renewal time has to be longer than the ticket lifetime in order to get 'renewable' flag set. -- / Alexander Bokovoy From jhrozek at redhat.com Fri Nov 7 09:18:31 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 7 Nov 2014 10:18:31 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> Message-ID: <20141107091831.GM14368@hendrix.brq.redhat.com> On Thu, Nov 06, 2014 at 09:33:35PM -0800, Michael Lasevich wrote: > For what its worth, my issue was resolved when I rebooted the server. > > Restarting sssd and/or clearing it's cache did not do it, but a full reboot > seems to have done it. Something much have been cached or some temp file I > missed. Will need to look into it further as I have a number of servers yet > to be upgraded and having to reboot linux servers to do an upgrade seem > sacrilegious... We need to see the krb5_child.log file ideally with a very high debug_level (10 would enable KRB5_TRACE debugging as well..) > > -M > > On Thu, Nov 6, 2014 at 9:26 PM, David Taylor > wrote: > > > As an add on, I?ve upgraded our Xen template to 6.6 and run up a new VM > > using that and it attaches to the IPA environment perfectly well, so I?m > > guessing it is an issue with the upgrade scripts. > > > > > > > > > > > > Best regards > > > > *David Taylor* > > > > *From:* Michael Lasevich [mailto:mlasevich at gmail.com] > > *Sent:* Friday, 7 November 2014 4:00 PM > > *To:* Jakub Hrozek > > *Cc:* David Taylor; freeipa-users at redhat.com > > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to > > 6.6 > > > > > > > > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to 1.11 > > (centos 6.5 to 6.6) > > > > > > > > I seem to be able to log in via ssh, but when I use http pam service, I > > get inconsistent behavior - seems like sometimes it works and others it > > errors out (success and failure can happen within a second) > > > > > > > > In the logs I see things like: > > > > > > > > [sssd[krb5_child[15410]]]: Internal credentials cache error > > > > and > > > > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= > > user=username > > received for user username: 4 (System error) > > > > Nothing in the audit.log that I can see > > > > I am guessing this is an sssd issue but I am hoping someone here knows how > > to deal with it. > > > > IN case it matters - here is the pam config: > > > > auth required pam_env.so > > auth sufficient pam_sss.so > > auth required pam_deny.so > > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > account required pam_permit.so > > > > password requisite pam_cracklib.so try_first_pass retry=3 type= > > password sufficient pam_sss.so use_authtok > > password required pam_deny.so > > > > > > > > session optional pam_keyinit.so revoke > > session required pam_limits.so > > session optional pam_oddjob_mkhomedir.so > > session [success=1 default=ignore] pam_succeed_if.so service in crond > > quiet use_uid > > session optional pam_sss.so > > > > -M > > > > > > > > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek wrote: > > > > On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > > > Thanks for the reply. The PAM file is pretty stock for a centos build > > > > > > #%PAM-1.0 > > > # This file is auto-generated. > > > # User changes will be destroyed the next time authconfig is run. > > > auth required pam_env.so > > > auth sufficient pam_unix.so nullok try_first_pass > > > auth requisite pam_succeed_if.so uid >= 500 quiet > > > auth sufficient pam_sss.so use_first_pass > > > auth required pam_deny.so > > > > > > account required pam_unix.so > > > account sufficient pam_localuser.so > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > account required pam_permit.so > > > > > > password requisite pam_cracklib.so try_first_pass retry=3 type= > > > password sufficient pam_unix.so sha512 shadow nullok > > try_first_pass use_authtok > > > password sufficient pam_sss.so use_authtok > > > password required pam_deny.so > > > > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session [success=1 default=ignore] pam_succeed_if.so service in > > crond quiet use_uid > > > session required pam_unix.so > > > session optional pam_sss.so > > > > > > > > > Best regards > > > David Taylor > > > > OK, so pam_sss is there ... > > > > And yet you see no mention of pam_sss.so in /var/log/secure ? > > > > Is this the file that was included from the service-specific PAM > > 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 > > > > > > From mbasti at redhat.com Fri Nov 7 09:25:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 10:25:51 +0100 Subject: [Freeipa-users] DS failed after upgrade In-Reply-To: <545C8850.4000401@redhat.com> References: <545C8850.4000401@redhat.com> Message-ID: <545C901F.1060701@redhat.com> Changed subject. Rob CCed On 07/11/14 09:52, Martin Basti wrote: > Forward message back to list > > > -------- Original Message -------- > Subject: Re: [Freeipa-users] dns stops working after upgrade > Date: Thu, 6 Nov 2014 21:42:55 +0100 > From: Rob Verduijn > To: Martin Basti > > > > Hi again, > > I tried the update to 4.1.1 > It didn't went well, actually it went worse than to 4.1. > Now the directory service went down and was no longer able to start. > > Some part of the logs is below. > Besides the warnings about a weak cipher there was not much in the > journalctl. > > It's getting late overhere, I'll dig into the logs tomorrow. > > Rob > > Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory > Server TJAKO-THUIS.... > Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory > Server TJAKO-THUIS.. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 is > weak. It is enabled since allowWeakCipher is "on" (default setting for > the backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 is > weak. It is enabled since allowWeakCipher is "on" (default setting for > the backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 is > weak. It is enabled since allowWeakCipher is "on" (default setting for > the backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is weak. > It is enabled since allowWeakCipher is "on" (default setting for the > backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha is > weak. It is enabled since allowWeakCipher is "on" (default setting for > the backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is weak. > It is enabled since allowWeakCipher is "on" (default setting for the > backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_3des_sha is > weak. It is enabled since allowWeakCipher is "on" (default setting for > the backward compatibility). We strongly recommend to set it to "off". > Please replace the value of allowWeakCipher with "off" in the > encryption config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza is not > available in NSS 3.17. Ignoring fortezza > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite > fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring > fortezza_rc4_128_sha > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_null > is not available in NSS 3.17. Ignoring fortezza_null > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher > tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward > compatibility). We strongly recommend to set it to "off". Please > replace the value of allowWeakCipher with "off" in the encryption > config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher > tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward > compatibility). We strongly recommend to set it to "off". Please > replace the value of allowWeakCipher with "off" in the encryption > config entry cn=encryption,cn=config and restart the server. > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_RC4_128_MD5: > enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_DES_CBC_SHA: > enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] - SSL alert: > TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: > [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL version range: > min: TLS1.0, max: TLS1.2 > Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: > dirsrv at TJAKO-THUIS.service: main process exited, code=exited, > status=1/FAILURE > Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit > dirsrv at TJAKO-THUIS.service entered failed state. > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Nov 7 09:32:17 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 7 Nov 2014 10:32:17 +0100 Subject: [Freeipa-users] unable to sudo In-Reply-To: <8a59418a5c6846949a52980386fc90b9@BLUPR08MB488.namprd08.prod.outlook.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> <20141106011111.5922961.60764.834@tetrioncapital.com> <20141106163350.GB31611@mail.corp.redhat.com> <8a59418a5c6846949a52980386fc90b9@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <20141107093217.GO14368@hendrix.brq.redhat.com> On Thu, Nov 06, 2014 at 07:27:04PM +0000, Craig White wrote: > -----Original Message----- > From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > Sent: Thursday, November 06, 2014 9:34 AM > To: Craig White > Cc: tlau at tetrioncapital.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] unable to sudo > > On (06/11/14 15:42), Craig White wrote: > >As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but ? once I did so, it pointed out that the Rackspace RHEL packaging that doesn?t provide what I need ? possibly need from epel. > > > > ># yum search /usr/lib64/libsss_sudo.so > This file was in separate package in sssd 1.9. The packaging was changed in sssd >= 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 > ---- > Unfortunately for me, Rackspace still has these boxes on RHEL 6.5 > > # rpm -qa | grep sssd > sssd-client-1.9.2-129.el6_5.4.x86_64 > sssd-1.9.2-129.el6_5.4.x86_64 > > nowhere to go I think - thanks I find it odd that they'd only give you half of the packages. Anyway, can you grab libsss_sudo RPMs from CentOS ? From mkosek at redhat.com Fri Nov 7 09:46:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 10:46:00 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> Message-ID: <545C94D8.4080509@redhat.com> On 11/05/2014 09:20 PM, Natxo Asenjo wrote: > On Wed, Nov 5, 2014 at 7:45 PM, Natxo Asenjo wrote: >> And I think I found it: >> https://fedorahosted.org/freeipa/ticket/3727 >> >> >> permissions of that folder: >> >> $ ls -ld publish/ >> drwxr-xr-x. 2 root root 73728 Jun 13 2013 publish/ >> >> I just changed them to pkiuser:pkiuser, let's see what the next run does. > > and it's fixed (after undoing the change in CS.cfg and re-setting > > ca.crl.MasterCRL.enableCRLCache=false > ca.crl.MasterCRL.enableCRLUpdates=false > > both to true and reloading pki-cad): > > -rw-rw-r--. 1 pkiuser pkiuser 1807 Jun 28 2013 MasterCRL-20130628-210000.der > -rw-rw-r--. 1 pkiuser pkiuser 5278 Nov 5 21:00 MasterCRL-20141105-210000.der > lrwxrwxrwx. 1 pkiuser pkiuser 57 Nov 5 21:00 MasterCRL.bin -> > /var/lib/ipa/pki-ca/publish/MasterCRL-20141105-210000.der > > phew Good! I am glad you fixed the problem. I added this case to http://www.freeipa.org/page/Troubleshooting#CRL_gets_very_old I am wondering what caused the issue. In the beginning you wrote that you use centos 6.5. However, the bug you correctly referred to was fixed in 6.5: https://bugzilla.redhat.com/show_bug.cgi?id=975431 So I am wondering if some scenario was missed and for example the IPA updater did not fix the folder ownership. Thanks, Martin From mkosek at redhat.com Fri Nov 7 09:48:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 10:48:32 +0100 Subject: [Freeipa-users] ATTN: CVE-2014-7828 In-Reply-To: <20141105204332.GO4107@redhat.com> References: <20141105204332.GO4107@redhat.com> Message-ID: <545C9570.40004@redhat.com> On 11/05/2014 09:43 PM, Alexander Bokovoy wrote: > Hi, > > Heads up for those who are using 2FA feature of FreeIPA 4.0 and 4.1. > A security issue was identified in the released versions of FreeIPA 4.0 > and 4.1 that makes possible for users with enabled OTP token to > authenticate using only the second factor. > > We have a fix available already and will be doing releases for 4.0.5 and > 4.1.1 tomorrow to get packages into Fedora 21, COPR repos, and Debian > Unstable. > > In meantime, you can mitigate by disabling OTP authentication for the > users. > > Sorry for inconvenience. > > https://fedorahosted.org/freeipa/ticket/4690 Just to close the thread, FreeIPA releases fixing the CVE are now in both Fedora 21 updates-testing repository and also in the main Copr repository. Details also in http://www.freeipa.org/page/CVE-2014-7828 Martin From natxo.asenjo at gmail.com Fri Nov 7 11:50:42 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 7 Nov 2014 12:50:42 +0100 Subject: [Freeipa-users] mastercrl.bin very old In-Reply-To: <545C94D8.4080509@redhat.com> References: <543C119C.8070509@redhat.com> <5447CFAE.2040206@redhat.com> <5457AB89.9080506@redhat.com> <5459E237.90803@redhat.com> <545C94D8.4080509@redhat.com> Message-ID: hi Martin, On Fri, Nov 7, 2014 at 10:46 AM, Martin Kosek wrote: > Good! I am glad you fixed the problem. I added this case to > http://www.freeipa.org/page/Troubleshooting#CRL_gets_very_old nice. Hopefully it will help someone. > I am wondering what caused the issue. In the beginning you wrote that you > use centos 6.5. However, the bug you correctly referred to was fixed in 6.5: > https://bugzilla.redhat.com/show_bug.cgi?id=975431 > > So I am wondering if some scenario was missed and for example the IPA > updater did not fix the folder ownership. Maybe there is a difference between the RHEL and centos rpm's ... I guess it's time to start monitoring the crl as well for (plenty of choice in the nagios exchange, apparently). Thanks for the tip! -- Groeten, natxo From rob.verduijn at gmail.com Fri Nov 7 12:52:35 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 7 Nov 2014 13:52:35 +0100 Subject: [Freeipa-users] DS failed after upgrade In-Reply-To: <545C901F.1060701@redhat.com> References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> Message-ID: Hi all, Either I was to worn out last night, or another update has happened. This morning the directory server did start after the update. local dns zones however where not available again after the update ipa-ldap-updater did not help to fix it. The are again only 7 DNS aci objects are still in the ds.( same as before when it failed ) I also noticed that there are also quite a lot lower case dns aci objects. Rob 2014-11-07 10:25 GMT+01:00 Martin Basti : > Changed subject. > Rob CCed > > On 07/11/14 09:52, Martin Basti wrote: > > Forward message back to list > > > -------- Original Message -------- Subject: Re: [Freeipa-users] dns > stops working after upgrade Date: Thu, 6 Nov 2014 21:42:55 +0100 From: Rob > Verduijn To: Martin > Basti > > Hi again, > > I tried the update to 4.1.1 > It didn't went well, actually it went worse than to 4.1. > Now the directory service went down and was no longer able to start. > > Some part of the logs is below. > Besides the warnings about a weak cipher there was not much in the > journalctl. > > It's getting late overhere, I'll dig into the logs tomorrow. > > Rob > > Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory > Server TJAKO-THUIS.... > Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory > Server TJAKO-THUIS.. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_des_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_fips_des_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_3des_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher rsa_fips_3des_sha is weak. It is enabled since > allowWeakCipher is "on" (default setting for the backward compatibility). > We strongly recommend to set it to "off". Please replace the value of > allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher suite fortezza is not available in NSS 3.17. > Ignoring fortezza > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher suite fortezza_rc4_128_sha is not available in > NSS 3.17. Ignoring fortezza_rc4_128_sha > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher suite fortezza_null is not available in NSS > 3.17. Ignoring fortezza_null > Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 > +0100] - SSL alert: Cipher tls_rsa_export1024_with_rc4_56_sha is weak. It > is enabled since allowWeakCipher is "on" (default setting for the backward > compatibility). We strongly recommend to set it to "off". Please replace > the value of allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: Cipher tls_rsa_export1024_with_des_cbc_sha is weak. It > is enabled since allowWeakCipher is "on" (default setting for the backward > compatibility). We strongly recommend to set it to "off". Please replace > the value of allowWeakCipher with "off" in the encryption config entry > cn=encryption,cn=config and restart the server. > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: Configured NSS Ciphers > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, > (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK > CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK > CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, > (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, > (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK > CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, > (WEAK CIPHER) > Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 > +0100] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 > Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: dirsrv at TJAKO-THUIS.service: > main process exited, code=exited, status=1/FAILURE > Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit > dirsrv at TJAKO-THUIS.service entered failed state. > > > > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Nov 7 12:56:25 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 13:56:25 +0100 Subject: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade) In-Reply-To: References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> Message-ID: <545CC179.2020102@redhat.com> On 07/11/14 13:52, Rob Verduijn wrote: > Hi all, > > Either I was to worn out last night, or another update has happened. > This morning the directory server did start after the update. > local dns zones however where not available again after the update > ipa-ldap-updater did not help to fix it. > > The are again only 7 DNS aci objects are still in the ds.( same as > before when it failed ) > I also noticed that there are also quite a lot lower case dns aci objects. > > Rob > > Hi, do you have any errors in /var/log/ipaupgrade.log ? > > > 2014-11-07 10:25 GMT+01:00 Martin Basti >: > > Changed subject. > Rob CCed > > On 07/11/14 09:52, Martin Basti wrote: >> Forward message back to list >> >> >> -------- Original Message -------- >> Subject: Re: [Freeipa-users] dns stops working after upgrade >> Date: Thu, 6 Nov 2014 21:42:55 +0100 >> From: Rob Verduijn >> >> To: Martin Basti >> >> >> >> Hi again, >> >> I tried the update to 4.1.1 >> It didn't went well, actually it went worse than to 4.1. >> Now the directory service went down and was no longer able to start. >> >> Some part of the logs is below. >> Besides the warnings about a weak cipher there was not much in >> the journalctl. >> >> It's getting late overhere, I'll dig into the logs tomorrow. >> >> Rob >> >> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 >> Directory Server TJAKO-THUIS.... >> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 >> Directory Server TJAKO-THUIS.. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 >> is weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 >> is weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 >> is weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is >> weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha >> is weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is >> weak. It is enabled since allowWeakCipher is "on" (default >> setting for the backward compatibility). We strongly recommend to >> set it to "off". Please replace the value of allowWeakCipher >> with "off" in the encryption config entry cn=encryption,cn=config >> and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >> rsa_fips_3des_sha is weak. It is enabled since allowWeakCipher is >> "on" (default setting for the backward compatibility). We >> strongly recommend to set it to "off". Please replace the value >> of allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza >> is not available in NSS 3.17. Ignoring fortezza >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >> fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring >> fortezza_rc4_128_sha >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >> fortezza_null is not available in NSS 3.17. Ignoring fortezza_null >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >> tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward >> compatibility). We strongly recommend to set it to "off". Please >> replace the value of allowWeakCipher with "off" in the encryption >> config entry cn=encryption,cn=config and restart the server. >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher >> tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward >> compatibility). We strongly recommend to set it to "off". Please >> replace the value of allowWeakCipher with "off" in the encryption >> config entry cn=encryption,cn=config and restart the server. >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] - SSL alert: >> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >> [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL version >> range: min: TLS1.0, max: TLS1.2 >> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: >> dirsrv at TJAKO-THUIS.service : >> main process exited, code=exited, status=1/FAILURE >> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit >> dirsrv at TJAKO-THUIS.service >> entered failed state. >> >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From traiano at gmail.com Fri Nov 7 13:08:15 2014 From: traiano at gmail.com (Traiano Welcome) Date: Fri, 7 Nov 2014 16:08:15 +0300 Subject: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address Message-ID: Hi List I'm trying to configure a replica for a primary freeipa IdM server (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install" fails with the following error: -- ipa-replica-install -d --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg . . Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use IP network address . . -- For context, here is the full output from the replica-install command (I've attached the full debug output): --- [root at lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at IDM.LOCAL password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'lolpr-idm-slve.idm.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use IP network address [root at lolpr-idm-slve ipa]# --- Some things I've tested: 1. disable selinux (followed by reboot) - no change 2. disable IPv6 (followed by reboot) - no change DNS resolution and IP checks seem fine: --- [root at lolpr-idm-slve install]# hostname lolpr-idm-slve.idm.local [root at lolpr-idm-slve install]# ifconfig ens192: flags=4163 mtu 1500 inet 172.16.100.222 netmask 255.255.255.255 broadcast 172.16.100.222 ether 00:50:56:9c:1e:60 txqueuelen 1000 (Ethernet) RX packets 17964 bytes 1705674 (1.6 MiB) RX errors 0 dropped 10 overruns 0 frame 0 TX packets 3772 bytes 595134 (581.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -- /etc/hosts looks like this: -- 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 172.16.100.68 lolpr-idm-mstr.idm.local lolpr-idm-mstr 172.16.100.222 lolpr-idm-slve.idm.local lolpr-idm-slve 172.16.104.231 loltestdc001.loltestdc.com loltestdc001 -- Host naming, forward and reverse resolution seems fine: --- [root at lolpr-idm-slve install]# [root at lolpr-idm-slve install]# host `hostname` lolpr-idm-slve.idm.local has address 172.16.100.222 [root at lolpr-idm-slve install]# [root at lolpr-idm-slve install]# host `hostname`^C [root at lolpr-idm-slve install]# host `hostname`| cut -d " " -f 4| xargs -Iname host name 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local. [root at lolpr-idm-slve install]# --- I'd be thankful if anyone could shed a light on why this error is happening and point me in the direction of a fix. Kind Regards, Traiano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ipa : DEBUG stdout=enabled ipa : DEBUG stderr= WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd Directory Manager (existing master) password: ipa : DEBUG Starting external process ipa : DEBUG args=/usr/bin/gpg-agent --batch --homedir /tmp/tmpIaHxbXipa/ipa-Ae8JB2/.gnupg --daemon /usr/bin/gpg --batch --homedir /tmp/tmpIaHxbXipa/ipa-Ae8JB2/.gnupg --passphrase-fd 0 --yes --no-tty -o /tmp/tmpIaHxbXipa/files.tar -d /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg ipa : DEBUG Process finished, return code=0 ipa : DEBUG Starting external process ipa : DEBUG args=tar xf /tmp/tmpIaHxbXipa/files.tar -C /tmp/tmpIaHxbXipa ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG Installing replica file with version 30303 (0 means no version in prepared file). ipa : DEBUG Check if lolpr-idm-slve.idm.local is a primary hostname for localhost ipa : DEBUG Primary hostname for localhost: lolpr-idm-slve.idm.local ipa : DEBUG Search DNS for lolpr-idm-slve.idm.local ipa : DEBUG Check if lolpr-idm-slve.idm.local is not a CNAME ipa : DEBUG Check reverse address of 172.16.100.222 ipa : DEBUG Found reverse name: lolpr-idm-slve.idm.local ipa : DEBUG Check if lolpr-idm-mstr.idm.local is a primary hostname for localhost ipa : DEBUG Primary hostname for localhost: lolpr-idm-mstr.idm.local ipa : DEBUG Search DNS for lolpr-idm-mstr.idm.local ipa : DEBUG Check if lolpr-idm-mstr.idm.local is not a CNAME ipa : DEBUG Check reverse address of 172.16.100.68 ipa : DEBUG Found reverse name: lolpr-idm-mstr.idm.local Run connection check to master ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master lolpr-idm-mstr.idm.local --auto-master-check --realm IDM.LOCAL --principal admin --hostname lolpr-idm-slve.idm.local Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at IDM.LOCAL password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'lolpr-idm-slve.idm.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. ipa : DEBUG Process finished, return code=0 Connection check OK ipa : DEBUG Starting external process ipa : DEBUG args=/sbin/ip -family inet -oneline address show ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 2: ens192 inet 172.16.100.222/32 brd 172.16.100.222 scope global ens192\ valid_lft forever preferred_lft forever ipa : DEBUG stderr= ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/sbin/ipa-replica-install", line 554, in main config.ip = installutils.get_server_ip_address(config.host_name, fstore, True, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 459, in get_server_ip_address sys.exit("Invalid IP Address %s for %s: %s" % (hostaddr[0], host_name, unicode(e))) ipa : DEBUG The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use IP network address Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use IP network address --- From rob.verduijn at gmail.com Fri Nov 7 13:26:53 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 7 Nov 2014 14:26:53 +0100 Subject: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade) In-Reply-To: <545CC179.2020102@redhat.com> References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> <545CC179.2020102@redhat.com> Message-ID: Hello, Yes this time there are This section : 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential integrity postoperation,cn=plugins,cn=config 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2014-11-07T13:10:03Z ERROR Update failed: Operations error: and this one 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis 2014-11-07T13:10:18Z ERROR Add failure and this one: (but since I do not have AD it's kinda logical) 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis 2014-11-07T13:10:19Z ERROR Upgrade failed with 2014-11-07T13:10:19Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 152, in __upgrade self.modified = (ld.update(self.files, ordered=True) or File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 874, in update updates = api.Backend.updateclient.update(POST_UPDATE, self.dm_password, self.ldapi, self.live_run) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", line 123, in update (restart, apply_now, res) = self.run(update.name, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", line 146, in run return self.Updater[method](**kw) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399, in __call__ return self.execute(**options) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line 89, in execute api.Command.dnszone_mod(zone[u'idnsname'][0], **update) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2528, in execute result = super(dnszone_mod, self).execute(*keys, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1385, in execute dn = self.obj.get_dn(*keys, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1784, in get_dn assert zone.is_absolute() AssertionError 2014-11-07T13:10:23Z ERROR IPA upgrade failed. 2014-11-07T13:10:23Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 151, in run raise admintool.ScriptError('IPA upgrade failed.', 1) 2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, exception: ScriptError: IPA upgrade failed. 2014-11-07T13:10:23Z ERROR IPA upgrade failed. 2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} 2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20 and another 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential integrity postoperation,cn=plugins,cn=config 2014-11-07T13:10:03Z DEBUG Live 1, updated 1 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2014-11-07T13:10:03Z ERROR Update failed: Operations error: That's it Rob 2014-11-07 13:56 GMT+01:00 Martin Basti : > On 07/11/14 13:52, Rob Verduijn wrote: > > Hi all, > > Either I was to worn out last night, or another update has happened. > This morning the directory server did start after the update. > local dns zones however where not available again after the update > ipa-ldap-updater did not help to fix it. > > The are again only 7 DNS aci objects are still in the ds.( same as > before when it failed ) > I also noticed that there are also quite a lot lower case dns aci objects. > > Rob > > > Hi, > > do you have any errors in /var/log/ipaupgrade.log ? > > > > 2014-11-07 10:25 GMT+01:00 Martin Basti : > >> Changed subject. >> Rob CCed >> >> On 07/11/14 09:52, Martin Basti wrote: >> >> Forward message back to list >> >> >> -------- Original Message -------- Subject: Re: [Freeipa-users] dns >> stops working after upgrade Date: Thu, 6 Nov 2014 21:42:55 +0100 From: Rob >> Verduijn To: Martin >> Basti >> >> Hi again, >> >> I tried the update to 4.1.1 >> It didn't went well, actually it went worse than to 4.1. >> Now the directory service went down and was no longer able to start. >> >> Some part of the logs is below. >> Besides the warnings about a weak cipher there was not much in the >> journalctl. >> >> It's getting late overhere, I'll dig into the logs tomorrow. >> >> Rob >> >> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory >> Server TJAKO-THUIS.... >> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory >> Server TJAKO-THUIS.. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_des_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_fips_des_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_3des_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher rsa_fips_3des_sha is weak. It is enabled since >> allowWeakCipher is "on" (default setting for the backward compatibility). >> We strongly recommend to set it to "off". Please replace the value of >> allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher suite fortezza is not available in NSS 3.17. >> Ignoring fortezza >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher suite fortezza_rc4_128_sha is not available in >> NSS 3.17. Ignoring fortezza_rc4_128_sha >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher suite fortezza_null is not available in NSS >> 3.17. Ignoring fortezza_null >> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:58 >> +0100] - SSL alert: Cipher tls_rsa_export1024_with_rc4_56_sha is weak. It >> is enabled since allowWeakCipher is "on" (default setting for the backward >> compatibility). We strongly recommend to set it to "off". Please replace >> the value of allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: Cipher tls_rsa_export1024_with_des_cbc_sha is weak. It >> is enabled since allowWeakCipher is "on" (default setting for the backward >> compatibility). We strongly recommend to set it to "off". Please replace >> the value of allowWeakCipher with "off" in the encryption config entry >> cn=encryption,cn=config and restart the server. >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: Configured NSS Ciphers >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, >> (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK >> CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK >> CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, >> (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, >> (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK >> CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] - SSL alert: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, >> (WEAK CIPHER) >> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: [06/Nov/2014:21:34:59 >> +0100] SSL Initialization - SSL version range: min: TLS1.0, max: TLS1.2 >> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: >> dirsrv at TJAKO-THUIS.service: main process exited, code=exited, >> status=1/FAILURE >> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit >> dirsrv at TJAKO-THUIS.service entered failed state. >> >> >> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Nov 7 13:55:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 14:55:18 +0100 Subject: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade) In-Reply-To: References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> <545CC179.2020102@redhat.com> Message-ID: <545CCF46.9010202@redhat.com> On 07/11/14 14:26, Rob Verduijn wrote: > Hello, > > Yes this time there are > This section : > 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential > integrity postoperation,cn=plugins,cn=config > > 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: > {'desc': 'Operations error'} > 2014-11-07T13:10:03Z ERROR Update failed: Operations error: > > and this one > 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust > Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis > > 2014-11-07T13:10:18Z ERROR Add failure Known issues > and this one: (but since I do not have AD it's kinda logical) > 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust > Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis > > 2014-11-07T13:10:19Z ERROR Upgrade failed with > 2014-11-07T13:10:19Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > line 152, in __upgrade > self.modified = (ld.update(self.files, ordered=True) or > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 874, in update > updates = api.Backend.updateclient.update(POST_UPDATE, > self.dm_password, self.ldapi, self.live_run) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", > line 123, in update > (restart, apply_now, res) = self.run(update.name > , **kw) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", > line 146, in run > return self.Updater[method](**kw) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 1399, in __call__ > return self.execute(**options) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", > line 89, in execute > api.Command.dnszone_mod(zone[u'idnsname'][0], **update) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 439, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 754, in run > return self.execute(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line > 2528, in execute > result = super(dnszone_mod, self).execute(*keys, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", > line 1385, in execute > dn = self.obj.get_dn(*keys, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line > 1784, in get_dn > assert zone.is_absolute() > AssertionError This is the problem, it is new bug. The workaround is replace the code in: /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68 - zones = api.Command.dnszone_find(all=True)['result'] + zones = api.Command.dnszone_find(all=True, raw=True)['result'] (I didn't test it) and run ipa-ldap-updater --upgrade Thank you for patience. > > 2014-11-07T13:10:23Z ERROR IPA upgrade failed. > 2014-11-07T13:10:23Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, > in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", > line 151, in run > raise admintool.ScriptError('IPA upgrade failed.', 1) > > 2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, > exception: ScriptError: IPA upgrade failed. > 2014-11-07T13:10:23Z ERROR IPA upgrade failed. > 2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked > with options: {'debug': False, 'quiet': True} > 2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20 > > > and another > 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential > integrity postoperation,cn=plugins,cn=config > > 2014-11-07T13:10:03Z DEBUG Live 1, updated 1 > 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: > {'desc': 'Operations error'} > 2014-11-07T13:10:03Z ERROR Update failed: Operations error: > > That's it > Rob > > > > > 2014-11-07 13:56 GMT+01:00 Martin Basti >: > > On 07/11/14 13:52, Rob Verduijn wrote: >> Hi all, >> >> Either I was to worn out last night, or another update has happened. >> This morning the directory server did start after the update. >> local dns zones however where not available again after the update >> ipa-ldap-updater did not help to fix it. >> >> The are again only 7 DNS aci objects are still in the ds.( same >> as before when it failed ) >> I also noticed that there are also quite a lot lower case dns aci >> objects. >> >> Rob >> >> > Hi, > > do you have any errors in /var/log/ipaupgrade.log ? >> >> >> 2014-11-07 10:25 GMT+01:00 Martin Basti > >: >> >> Changed subject. >> Rob CCed >> >> On 07/11/14 09:52, Martin Basti wrote: >>> Forward message back to list >>> >>> >>> -------- Original Message -------- >>> Subject: Re: [Freeipa-users] dns stops working after upgrade >>> Date: Thu, 6 Nov 2014 21:42:55 +0100 >>> From: Rob Verduijn >>> >>> To: Martin Basti >>> >>> >>> >>> >>> Hi again, >>> >>> I tried the update to 4.1.1 >>> It didn't went well, actually it went worse than to 4.1. >>> Now the directory service went down and was no longer able >>> to start. >>> >>> Some part of the logs is below. >>> Besides the warnings about a weak cipher there was not much >>> in the journalctl. >>> >>> It's getting late overhere, I'll dig into the logs tomorrow. >>> >>> Rob >>> >>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 >>> Directory Server TJAKO-THUIS.... >>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 >>> Directory Server TJAKO-THUIS.. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_rc4_128_md5 is weak. It is enabled since allowWeakCipher >>> is "on" (default setting for the backward compatibility). We >>> strongly recommend to set it to "off". Please replace the >>> value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_rc4_40_md5 is weak. It is enabled since allowWeakCipher >>> is "on" (default setting for the backward compatibility). We >>> strongly recommend to set it to "off". Please replace the >>> value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_rc2_40_md5 is weak. It is enabled since allowWeakCipher >>> is "on" (default setting for the backward compatibility). We >>> strongly recommend to set it to "off". Please replace the >>> value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha >>> is weak. It is enabled since allowWeakCipher is "on" >>> (default setting for the backward compatibility). We >>> strongly recommend to set it to "off". Please replace the >>> value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_fips_des_sha is weak. It is enabled since >>> allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". >>> Please replace the value of allowWeakCipher with "off" in >>> the encryption config entry cn=encryption,cn=config and >>> restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_3des_sha is weak. It is enabled since allowWeakCipher is >>> "on" (default setting for the backward compatibility). We >>> strongly recommend to set it to "off". Please replace the >>> value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> rsa_fips_3des_sha is weak. It is enabled since >>> allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". >>> Please replace the value of allowWeakCipher with "off" in >>> the encryption config entry cn=encryption,cn=config and >>> restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >>> fortezza is not available in NSS 3.17. Ignoring fortezza >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >>> fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring >>> fortezza_rc4_128_sha >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >>> fortezza_null is not available in NSS 3.17. Ignoring >>> fortezza_null >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled >>> since allowWeakCipher is "on" (default setting for the >>> backward compatibility). We strongly recommend to set it to >>> "off". Please replace the value of allowWeakCipher with >>> "off" in the encryption config entry cn=encryption,cn=config >>> and restart the server. >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher >>> tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled >>> since allowWeakCipher is "on" (default setting for the >>> backward compatibility). We strongly recommend to set it to >>> "off". Please replace the value of allowWeakCipher with >>> "off" in the encryption config entry cn=encryption,cn=config >>> and restart the server. >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL >>> version range: min: TLS1.0, max: TLS1.2 >>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: >>> dirsrv at TJAKO-THUIS.service >>> : main process exited, >>> code=exited, status=1/FAILURE >>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit >>> dirsrv at TJAKO-THUIS.service >>> entered failed state. >>> >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Fri Nov 7 14:05:05 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 7 Nov 2014 15:05:05 +0100 Subject: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade) In-Reply-To: <545CCF46.9010202@redhat.com> References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> <545CC179.2020102@redhat.com> <545CCF46.9010202@redhat.com> Message-ID: Yup that solved it. Everything looks ok now :-) Thank you for you great effort. Rob 2014-11-07 14:55 GMT+01:00 Martin Basti : > On 07/11/14 14:26, Rob Verduijn wrote: > > Hello, > > Yes this time there are > This section : > 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential > integrity postoperation,cn=plugins,cn=config > > 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: > {'desc': 'Operations error'} > 2014-11-07T13:10:03Z ERROR Update failed: Operations error: > > and this one > 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust > Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis > > 2014-11-07T13:10:18Z ERROR Add failure > > Known issues > > and this one: (but since I do not have AD it's kinda logical) > 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust > Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis > > 2014-11-07T13:10:19Z ERROR Upgrade failed with > 2014-11-07T13:10:19Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", > line 152, in __upgrade > self.modified = (ld.update(self.files, ordered=True) or > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 874, in update > updates = api.Backend.updateclient.update(POST_UPDATE, > self.dm_password, self.ldapi, self.live_run) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", > line 123, in update > (restart, apply_now, res) = self.run(update.name, **kw) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", > line 146, in run > return self.Updater[method](**kw) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399, > in __call__ > return self.execute(**options) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line > 89, in execute > api.Command.dnszone_mod(zone[u'idnsname'][0], **update) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in > run > return self.execute(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line > 2528, in execute > result = super(dnszone_mod, self).execute(*keys, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line > 1385, in execute > dn = self.obj.get_dn(*keys, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line > 1784, in get_dn > assert zone.is_absolute() > AssertionError > > > This is the problem, it is new bug. > > The workaround is replace the code in: > /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68 > - zones = api.Command.dnszone_find(all=True)['result'] > + zones = api.Command.dnszone_find(all=True, raw=True)['result'] > > (I didn't test it) > > and run ipa-ldap-updater --upgrade > > Thank you for patience. > > > > > 2014-11-07T13:10:23Z ERROR IPA upgrade failed. > 2014-11-07T13:10:23Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", > line 151, in run > raise admintool.ScriptError('IPA upgrade failed.', 1) > > 2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, > exception: ScriptError: IPA upgrade failed. > 2014-11-07T13:10:23Z ERROR IPA upgrade failed. > 2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with > options: {'debug': False, 'quiet': True} > 2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20 > > > and another > 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential > integrity postoperation,cn=plugins,cn=config > > 2014-11-07T13:10:03Z DEBUG Live 1, updated 1 > 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': > 'Operations error'} > 2014-11-07T13:10:03Z ERROR Update failed: Operations error: > > That's it > Rob > > > > > 2014-11-07 13:56 GMT+01:00 Martin Basti : > >> On 07/11/14 13:52, Rob Verduijn wrote: >> >> Hi all, >> >> Either I was to worn out last night, or another update has happened. >> This morning the directory server did start after the update. >> local dns zones however where not available again after the update >> ipa-ldap-updater did not help to fix it. >> >> The are again only 7 DNS aci objects are still in the ds.( same as >> before when it failed ) >> I also noticed that there are also quite a lot lower case dns aci objects. >> >> Rob >> >> >> Hi, >> >> do you have any errors in /var/log/ipaupgrade.log ? >> >> >> >> 2014-11-07 10:25 GMT+01:00 Martin Basti : >> >>> Changed subject. >>> Rob CCed >>> >>> On 07/11/14 09:52, Martin Basti wrote: >>> >>> Forward message back to list >>> >>> >>> -------- Original Message -------- Subject: Re: [Freeipa-users] dns >>> stops working after upgrade Date: Thu, 6 Nov 2014 21:42:55 +0100 From: >>> Rob Verduijn To: Martin >>> Basti >>> >>> Hi again, >>> >>> I tried the update to 4.1.1 >>> It didn't went well, actually it went worse than to 4.1. >>> Now the directory service went down and was no longer able to start. >>> >>> Some part of the logs is below. >>> Besides the warnings about a weak cipher there was not much in the >>> journalctl. >>> >>> It's getting late overhere, I'll dig into the logs tomorrow. >>> >>> Rob >>> >>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 Directory >>> Server TJAKO-THUIS.... >>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 Directory >>> Server TJAKO-THUIS.. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_128_md5 is weak. >>> It is enabled since allowWeakCipher is "on" (default setting for the >>> backward compatibility). We strongly recommend to set it to "off". Please >>> replace the value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 is weak. It >>> is enabled since allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". Please replace >>> the value of allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 is weak. It >>> is enabled since allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". Please replace >>> the value of allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is weak. It is >>> enabled since allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". Please replace >>> the value of allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_des_sha is weak. >>> It is enabled since allowWeakCipher is "on" (default setting for the >>> backward compatibility). We strongly recommend to set it to "off". Please >>> replace the value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha is weak. It >>> is enabled since allowWeakCipher is "on" (default setting for the backward >>> compatibility). We strongly recommend to set it to "off". Please replace >>> the value of allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_fips_3des_sha is weak. >>> It is enabled since allowWeakCipher is "on" (default setting for the >>> backward compatibility). We strongly recommend to set it to "off". Please >>> replace the value of allowWeakCipher with "off" in the encryption config >>> entry cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza is not >>> available in NSS 3.17. Ignoring fortezza >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_rc4_128_sha >>> is not available in NSS 3.17. Ignoring fortezza_rc4_128_sha >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza_null is not >>> available in NSS 3.17. Ignoring fortezza_null >>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>> tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled since >>> allowWeakCipher is "on" (default setting for the backward compatibility). >>> We strongly recommend to set it to "off". Please replace the value of >>> allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher >>> tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled since >>> allowWeakCipher is "on" (default setting for the backward compatibility). >>> We strongly recommend to set it to "off". Please replace the value of >>> allowWeakCipher with "off" in the encryption config entry >>> cn=encryption,cn=config and restart the server. >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_RC4_128_MD5: >>> enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: TLS_RSA_WITH_DES_CBC_SHA: >>> enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) >>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>> [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL version range: min: >>> TLS1.0, max: TLS1.2 >>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: >>> dirsrv at TJAKO-THUIS.service: main process exited, code=exited, >>> status=1/FAILURE >>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit >>> dirsrv at TJAKO-THUIS.service entered failed state. >>> >>> >>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrorourke at earthlink.net Fri Nov 7 14:15:22 2014 From: mrorourke at earthlink.net (Michael ORourke) Date: Fri, 7 Nov 2014 09:15:22 -0500 (GMT-05:00) Subject: [Freeipa-users] Kerberos for cronjoob Message-ID: <13220208.1415369722935.JavaMail.root@elwamui-little.atl.sa.earthlink.net> An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Nov 7 14:38:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 15:38:14 +0100 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: References: <5404092F.2090604@redhat.com> <540444FA.5090800@redhat.com> <54044785.4010302@redhat.com> <5406C25B.1000003@redhat.com> Message-ID: <545CD956.1030303@redhat.com> On 4.11.2014 16:57, Matthew Sellers wrote: > Hi Guys, > > Thanks for the previous replies. I hate to dig up and old thread, but im > still banging my head on this. I am trying to configure IPA to send notify > to slaves servers on manual updates from the web or CLI tools. > > Dynamic DNS updates from an IPA client issuing an nsupdate works great, I > get an immediate zone transfer to zone NS slaves ( bind 9.x slaves). > > Performing an update via IPA CLI ( for non-dynamic static record) tools > triggers nothing. The test documents and Petr's previous statements hold > true for the nsupdate case, is this also true for CLI driven updates as > well? > > I have tested this on 3.3.5 (Fedora 20) and 4.1 (COPR) release. Congratulations! You have found a regression in bind-dyndb-ldap: https://fedorahosted.org/bind-dyndb-ldap/ticket/144 I have sent patch to the devel list and it is waiting for review at the moment. It should be fixed in nearest release of bind-dyndb-ldap. Thank you very much for catching this! Petr^2 Spacek > On Wed, Sep 3, 2014 at 2:25 AM, Petr Spacek wrote: > >> On 1.9.2014 12:16, Dmitri Pal wrote: >> >>> On 09/01/2014 12:05 PM, Martin Kosek wrote: >>> >>>> On 09/01/2014 07:50 AM, Dmitri Pal wrote: >>>> >>>>> On 08/29/2014 09:32 PM, Matthew Sellers wrote: >>>>> >>>>>> Hi Everyone! >>>>>> >>>>>> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure >>>>>> FreeIPA to >>>>>> send notifies to non-IPA slaves, but it seems broken on IPA ( notify >>>>>> packets >>>>>> are never sent to to slaves ). >>>>>> >>>>>> I have configured also-notify { nameserverip; }; in named.conf on my >>>>>> FreeIPA >>>>>> test host in the options section and watched for notify traffic with >>>>>> tcpdump. >>>>>> >>>>>> This document suggests that this is supported, and this is something I >>>>>> have >>>>>> used in non-IPA bind servers with no issues. >>>>>> >>>>>> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer >>>>>> >>>>>> I wanted to ask the list before I file a bug with more details. Is >>>>>> anyone >>>>>> using this bind feature on IPA with any success? >>>>>> >>>>>> Thanks! >>>>>> Matt >>>>>> >>>>>> >>>>>> The DNS level change propagation is not supported between IPA >>>>> replicas instead >>>>> it uses LDAP replication to propagate the changes. >>>>> If you want another non IPA DNS server to be a slave then you can do >>>>> it. See >>>>> http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for >>>>> more >>>>> information. >>>>> >>>> I thought that from F20, bind-dyndb-ldap was capable of native DNS >>>> operations >>>> like AXFR/IXFR which can be used to actually deploy slave DNS servers. I >>>> wonder >>>> if also-notify is something different. CCing Petr Spacek to advise. >>>> >>> AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves - >>> no. >>> >> >> Let me summarize: >> - AXFR is supported (at least) by all versions RHEL 6.5 and newer versions >> - IXFR is supported by bind-dyndb-ldap 4.0 and newer (Fedora 20+) >> - DNS NOTIFY messages are always sent to servers listed in NS records >> >> I.e. you have to add your non-IPA slave servers to NS records in >> particular zone and then it should 'just work', no other configuration >> (like 'also-notify') is necessary. >> >> Please let me know if it doesn't work for you. From pspacek at redhat.com Fri Nov 7 15:19:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 16:19:09 +0100 Subject: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address In-Reply-To: References: Message-ID: <545CE2ED.7020309@redhat.com> On 7.11.2014 14:08, Traiano Welcome wrote: > Hi List > > I'm trying to configure a replica for a primary freeipa IdM server > (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install" > fails with the following error: > -- > ipa-replica-install -d --setup-ca --setup-dns --no-forwarders > /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg > . > . > Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use > IP network address > . > . > -- > > For context, here is the full output from the replica-install command (I've > attached the full debug output): > > --- > [root at lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns > --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg > WARNING: conflicting time&date synchronization service 'chronyd' will > be disabled in favor of ntpd > > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at IDM.LOCAL password: > > Check SSH connection to remote master > Execute check on remote master > Check connection from master to remote replica 'lolpr-idm-slve.idm.local': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > Connection from master to replica is OK. > > Connection check OK > Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use > IP network address > [root at lolpr-idm-slve ipa]# > > --- > > Some things I've tested: > > 1. disable selinux (followed by reboot) - no change > 2. disable IPv6 (followed by reboot) - no change > > DNS resolution and IP checks seem fine: > --- > > [root at lolpr-idm-slve install]# hostname > lolpr-idm-slve.idm.local > > > [root at lolpr-idm-slve install]# ifconfig > ens192: flags=4163 mtu 1500 > inet 172.16.100.222 netmask 255.255.255.255 broadcast > 172.16.100.222 This is the cause: IP address on ens192 interface is 172.16.100.222/32. What is your environment? Is it some kind of weird container? Is it even valid configuration? :-) I don't recall any use case for 32-bit netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point to point links. Petr^2 Spacek > ether 00:50:56:9c:1e:60 txqueuelen 1000 (Ethernet) > RX packets 17964 bytes 1705674 (1.6 MiB) > RX errors 0 dropped 10 overruns 0 frame 0 > TX packets 3772 bytes 595134 (581.1 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > -- > > /etc/hosts looks like this: > > -- > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > 172.16.100.68 lolpr-idm-mstr.idm.local lolpr-idm-mstr > 172.16.100.222 lolpr-idm-slve.idm.local lolpr-idm-slve > 172.16.104.231 loltestdc001.loltestdc.com loltestdc001 > -- > > Host naming, forward and reverse resolution seems fine: > > --- > [root at lolpr-idm-slve install]# > [root at lolpr-idm-slve install]# host `hostname` > lolpr-idm-slve.idm.local has address 172.16.100.222 > [root at lolpr-idm-slve install]# > [root at lolpr-idm-slve install]# host `hostname`^C > [root at lolpr-idm-slve install]# host `hostname`| cut -d " " -f 4| xargs > -Iname host name > 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local. > [root at lolpr-idm-slve install]# > --- > > I'd be thankful if anyone could shed a light on why this error is happening > and point me in the direction of a fix. > > Kind Regards, > Traiano > > > -- Petr^2 Spacek From mkosek at redhat.com Fri Nov 7 15:38:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 16:38:40 +0100 Subject: [Freeipa-users] DNS stops working after upgrade (was DS failed after upgrade) In-Reply-To: References: <545C8850.4000401@redhat.com> <545C901F.1060701@redhat.com> <545CC179.2020102@redhat.com> <545CCF46.9010202@redhat.com> Message-ID: <545CE780.6090409@redhat.com> On 11/07/2014 03:05 PM, Rob Verduijn wrote: > Yup that solved it. > > Everything looks ok now :-) > > Thank you for you great effort. Well, thank you for your patience. It will allow us to fix this bug in next FreeIPA release, the patch was already submitted on freeipa-devel. Thanks again! Martin > Rob > > 2014-11-07 14:55 GMT+01:00 Martin Basti >: > > On 07/11/14 14:26, Rob Verduijn wrote: >> Hello, >> >> Yes this time there are >> This section : >> 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential >> integrity postoperation,cn=plugins,cn=config >> >> 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >> {'desc': 'Operations error'} >> 2014-11-07T13:10:03Z ERROR Update failed: Operations error: >> >> and this one >> 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust >> Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis >> >> 2014-11-07T13:10:18Z ERROR Add failure > Known issues > >> and this one: (but since I do not have AD it's kinda logical) >> 2014-11-07T13:10:18Z INFO New entry: cn=ADTrust >> Agents,cn=privileges,cn=pbac,dc=tjako,dc=thuis >> >> 2014-11-07T13:10:19Z ERROR Upgrade failed with >> 2014-11-07T13:10:19Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >> line 152, in __upgrade >> self.modified = (ld.update(self.files, ordered=True) or >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line >> 874, in update >> updates = api.Backend.updateclient.update(POST_UPDATE, >> self.dm_password, self.ldapi, self.live_run) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", >> line 123, in update >> (restart, apply_now, res) = self.run(update.name >> , **kw) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py", >> line 146, in run >> return self.Updater[method](**kw) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1399, >> in __call__ >> return self.execute(**options) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line >> 89, in execute >> api.Command.dnszone_mod(zone[u'idnsname'][0], **update) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, >> in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, >> in run >> return self.execute(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line >> 2528, in execute >> result = super(dnszone_mod, self).execute(*keys, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >> line 1385, in execute >> dn = self.obj.get_dn(*keys, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line >> 1784, in get_dn >> assert zone.is_absolute() >> AssertionError > > This is the problem, it is new bug. > > The workaround is replace the code in: > /usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py:68 > - zones = api.Command.dnszone_find(all=True)['result'] > + zones = api.Command.dnszone_find(all=True, raw=True)['result'] > > (I didn't test it) > > and run ipa-ldap-updater --upgrade > > Thank you for patience. > > > >> >> 2014-11-07T13:10:23Z ERROR IPA upgrade failed. >> 2014-11-07T13:10:23Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >> execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", >> line 151, in run >> raise admintool.ScriptError('IPA upgrade failed.', 1) >> >> 2014-11-07T13:10:23Z DEBUG The ipa-ldap-updater command failed, >> exception: ScriptError: IPA upgrade failed. >> 2014-11-07T13:10:23Z ERROR IPA upgrade failed. >> 2014-11-07T13:10:23Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with >> options: {'debug': False, 'quiet': True} >> 2014-11-07T13:10:23Z DEBUG IPA version 4.1.1-1.fc20 >> >> >> and another >> 2014-11-07T13:10:03Z INFO Updating existing entry: cn=referential >> integrity postoperation,cn=plugins,cn=config >> >> 2014-11-07T13:10:03Z DEBUG Live 1, updated 1 >> 2014-11-07T13:10:03Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: >> {'desc': 'Operations error'} >> 2014-11-07T13:10:03Z ERROR Update failed: Operations error: >> >> That's it >> Rob >> >> >> >> >> 2014-11-07 13:56 GMT+01:00 Martin Basti > >: >> >> On 07/11/14 13:52, Rob Verduijn wrote: >>> Hi all, >>> >>> Either I was to worn out last night, or another update has happened. >>> This morning the directory server did start after the update. >>> local dns zones however where not available again after the update >>> ipa-ldap-updater did not help to fix it. >>> >>> The are again only 7 DNS aci objects are still in the ds.( same as >>> before when it failed ) >>> I also noticed that there are also quite a lot lower case dns aci >>> objects. >>> >>> Rob >>> >>> >> Hi, >> >> do you have any errors in /var/log/ipaupgrade.log ? >>> >>> >>> 2014-11-07 10:25 GMT+01:00 Martin Basti >> >: >>> >>> Changed subject. >>> Rob CCed >>> >>> On 07/11/14 09:52, Martin Basti wrote: >>>> Forward message back to list >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [Freeipa-users] dns stops working after upgrade >>>> Date: Thu, 6 Nov 2014 21:42:55 +0100 >>>> From: Rob Verduijn >>>> >>>> To: Martin Basti >>>> >>>> >>>> >>>> Hi again, >>>> >>>> I tried the update to 4.1.1 >>>> It didn't went well, actually it went worse than to 4.1. >>>> Now the directory service went down and was no longer able to >>>> start. >>>> >>>> Some part of the logs is below. >>>> Besides the warnings about a weak cipher there was not much in >>>> the journalctl. >>>> >>>> It's getting late overhere, I'll dig into the logs tomorrow. >>>> >>>> Rob >>>> >>>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Starting 389 >>>> Directory Server TJAKO-THUIS.... >>>> Nov 06 21:34:58 freeipa.tjako.thuis systemd[1]: Started 389 >>>> Directory Server TJAKO-THUIS.. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>>> rsa_rc4_128_md5 is weak. It is enabled since allowWeakCipher is >>>> "on" (default setting for the backward compatibility). We >>>> strongly recommend to set it to "off". Please replace the >>>> value of allowWeakCipher with "off" in the encryption config >>>> entry cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc4_40_md5 >>>> is weak. It is enabled since allowWeakCipher is "on" (default >>>> setting for the backward compatibility). We strongly recommend >>>> to set it to "off". Please replace the value of >>>> allowWeakCipher with "off" in the encryption config entry >>>> cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_rc2_40_md5 >>>> is weak. It is enabled since allowWeakCipher is "on" (default >>>> setting for the backward compatibility). We strongly recommend >>>> to set it to "off". Please replace the value of >>>> allowWeakCipher with "off" in the encryption config entry >>>> cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_des_sha is >>>> weak. It is enabled since allowWeakCipher is "on" (default >>>> setting for the backward compatibility). We strongly recommend >>>> to set it to "off". Please replace the value of >>>> allowWeakCipher with "off" in the encryption config entry >>>> cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>>> rsa_fips_des_sha is weak. It is enabled since allowWeakCipher >>>> is "on" (default setting for the backward compatibility). We >>>> strongly recommend to set it to "off". Please replace the >>>> value of allowWeakCipher with "off" in the encryption config >>>> entry cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher rsa_3des_sha >>>> is weak. It is enabled since allowWeakCipher is "on" (default >>>> setting for the backward compatibility). We strongly recommend >>>> to set it to "off". Please replace the value of >>>> allowWeakCipher with "off" in the encryption config entry >>>> cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>>> rsa_fips_3des_sha is weak. It is enabled since allowWeakCipher >>>> is "on" (default setting for the backward compatibility). We >>>> strongly recommend to set it to "off". Please replace the >>>> value of allowWeakCipher with "off" in the encryption config >>>> entry cn=encryption,cn=config and restart the server. >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite fortezza >>>> is not available in NSS 3.17. Ignoring fortezza >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >>>> fortezza_rc4_128_sha is not available in NSS 3.17. Ignoring >>>> fortezza_rc4_128_sha >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher suite >>>> fortezza_null is not available in NSS 3.17. Ignoring fortezza_null >>>> Nov 06 21:34:58 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:58 +0100] - SSL alert: Cipher >>>> tls_rsa_export1024_with_rc4_56_sha is weak. It is enabled >>>> since allowWeakCipher is "on" (default setting for the backward >>>> compatibility). We strongly recommend to set it to "off". >>>> Please replace the value of allowWeakCipher with "off" in the >>>> encryption config entry cn=encryption,cn=config and restart the >>>> server. >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Cipher >>>> tls_rsa_export1024_with_des_cbc_sha is weak. It is enabled >>>> since allowWeakCipher is "on" (default setting for the backward >>>> compatibility). We strongly recommend to set it to "off". >>>> Please replace the value of allowWeakCipher with "off" in the >>>> encryption config entry cn=encryption,cn=config and restart the >>>> server. >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: Configured NSS Ciphers >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_EXPORT_WITH_RC4_40_MD5: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] - SSL alert: >>>> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5: enabled, (WEAK CIPHER) >>>> Nov 06 21:34:59 freeipa.tjako.thuis ns-slapd[2244]: >>>> [06/Nov/2014:21:34:59 +0100] SSL Initialization - SSL version >>>> range: min: TLS1.0, max: TLS1.2 >>>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: >>>> dirsrv at TJAKO-THUIS.service : >>>> main process exited, code=exited, status=1/FAILURE >>>> Nov 06 21:35:01 freeipa.tjako.thuis systemd[1]: Unit >>>> dirsrv at TJAKO-THUIS.service >>>> entered failed state. >>>> >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > > > From CWhite at skytouchtechnology.com Fri Nov 7 15:44:08 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 7 Nov 2014 15:44:08 +0000 Subject: [Freeipa-users] unable to sudo In-Reply-To: <20141107093217.GO14368@hendrix.brq.redhat.com> References: <20bd853ff5544ee19ba147c8765adb18@BLUPR08MB488.namprd08.prod.outlook.com> <20141106011111.5922961.60764.834@tetrioncapital.com> <20141106163350.GB31611@mail.corp.redhat.com> <8a59418a5c6846949a52980386fc90b9@BLUPR08MB488.namprd08.prod.outlook.com> <20141107093217.GO14368@hendrix.brq.redhat.com> Message-ID: -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek Sent: Friday, November 07, 2014 2:32 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] unable to sudo On Thu, Nov 06, 2014 at 07:27:04PM +0000, Craig White wrote: > -----Original Message----- > From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > Sent: Thursday, November 06, 2014 9:34 AM > To: Craig White > Cc: tlau at tetrioncapital.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] unable to sudo > > On (06/11/14 15:42), Craig White wrote: > >As Bob pointed out in a direct e-mail to me, there was the detail of adding sudo and sss to /etc/nsswitch.conf but ? once I did so, it pointed out that the Rackspace RHEL packaging that doesn?t provide what I need ? possibly need from epel. > > > > ># yum search /usr/lib64/libsss_sudo.so > This file was in separate package in sssd 1.9. The packaging was changed in sssd >= 1.10 and it is installed by default (part of package sssd-common) and rhel/CentOS 6.6 contains sssd 1.11.6 > ---- > Unfortunately for me, Rackspace still has these boxes on RHEL 6.5 > > # rpm -qa | grep sssd > sssd-client-1.9.2-129.el6_5.4.x86_64 > sssd-1.9.2-129.el6_5.4.x86_64 > > nowhere to go I think - thanks I find it odd that they'd only give you half of the packages. Anyway, can you grab libsss_sudo RPMs from CentOS ? ---- Odd is a nice way of phrasing it. The thing is that these 2 servers are managed by Rackspace - hence the different repos. It may come down to installing epel or different repos or just waiting around to see what is packaged when they finally move to RHEL 6.6 and taking these boxes over from Rackspace management but that is not a decision made by someone in my pay grade ;-) Thanks Craig From traiano at gmail.com Fri Nov 7 16:20:37 2014 From: traiano at gmail.com (Traiano Welcome) Date: Fri, 7 Nov 2014 19:20:37 +0300 Subject: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address In-Reply-To: <545CE2ED.7020309@redhat.com> References: <545CE2ED.7020309@redhat.com> Message-ID: Hi Petr On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek wrote: > On 7.11.2014 14:08, Traiano Welcome wrote: >> Hi List >> >> I'm trying to configure a replica for a primary freeipa IdM server >> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install" >> fails with the following error: >> -- >> ipa-replica-install -d --setup-ca --setup-dns --no-forwarders >> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >> . >> . >> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >> IP network address >> . >> . >> -- >> >> For context, here is the full output from the replica-install command (I've >> attached the full debug output): >> >> --- >> [root at lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns >> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >> WARNING: conflicting time&date synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Directory Manager (existing master) password: >> >> Run connection check to master >> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> The following list of ports use UDP protocol and would need to be >> checked manually: >> Kerberos KDC: UDP (88): SKIPPED >> Kerberos Kpasswd: UDP (464): SKIPPED >> >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> admin at IDM.LOCAL password: >> >> Check SSH connection to remote master >> Execute check on remote master >> Check connection from master to remote replica 'lolpr-idm-slve.idm.local': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos KDC: UDP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> Kerberos Kpasswd: UDP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >> IP network address >> [root at lolpr-idm-slve ipa]# >> >> --- >> >> Some things I've tested: >> >> 1. disable selinux (followed by reboot) - no change >> 2. disable IPv6 (followed by reboot) - no change >> >> DNS resolution and IP checks seem fine: >> --- >> >> [root at lolpr-idm-slve install]# hostname >> lolpr-idm-slve.idm.local >> >> >> [root at lolpr-idm-slve install]# ifconfig >> ens192: flags=4163 mtu 1500 >> inet 172.16.100.222 netmask 255.255.255.255 broadcast >> 172.16.100.222 > > This is the cause: IP address on ens192 interface is 172.16.100.222/32. > > What is your environment? Is it some kind of weird container? > > Is it even valid configuration? :-) I don't recall any use case for 32-bit > netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point > to point links. > AFAIK, a /32 netmask designates a single address. Should be valid, although I'm not sure how IPA's installutils.py handles that. ipcalc says: ---- root at lol-dev:/opt/automation# ipcalc 172.16.100.222/32 Address: 172.16.100.222 10101100.00010000.01100100.11011110 Netmask: 255.255.255.255 = 32 11111111.11111111.11111111.11111111 Wildcard: 0.0.0.0 00000000.00000000.00000000.00000000 => Hostroute: 172.16.100.222 10101100.00010000.01100100.11011110 Hosts/Net: 1 Class B, Private Internet ---- Nice reference, seems to confirm this is a single host: http://www.oav.net/mirrors/cidr.html > Petr^2 Spacek > >> ether 00:50:56:9c:1e:60 txqueuelen 1000 (Ethernet) >> RX packets 17964 bytes 1705674 (1.6 MiB) >> RX errors 0 dropped 10 overruns 0 frame 0 >> TX packets 3772 bytes 595134 (581.1 KiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> -- >> >> /etc/hosts looks like this: >> >> -- >> 127.0.0.1 localhost localhost.localdomain localhost4 >> localhost4.localdomain4 >> 172.16.100.68 lolpr-idm-mstr.idm.local lolpr-idm-mstr >> 172.16.100.222 lolpr-idm-slve.idm.local lolpr-idm-slve >> 172.16.104.231 loltestdc001.loltestdc.com loltestdc001 >> -- >> >> Host naming, forward and reverse resolution seems fine: >> >> --- >> [root at lolpr-idm-slve install]# >> [root at lolpr-idm-slve install]# host `hostname` >> lolpr-idm-slve.idm.local has address 172.16.100.222 >> [root at lolpr-idm-slve install]# >> [root at lolpr-idm-slve install]# host `hostname`^C >> [root at lolpr-idm-slve install]# host `hostname`| cut -d " " -f 4| xargs >> -Iname host name >> 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local. >> [root at lolpr-idm-slve install]# >> --- >> >> I'd be thankful if anyone could shed a light on why this error is happening >> and point me in the direction of a fix. >> >> Kind Regards, >> Traiano >> >> >> > > > -- > 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 From pspacek at redhat.com Fri Nov 7 16:22:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 17:22:57 +0100 Subject: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address In-Reply-To: References: <545CE2ED.7020309@redhat.com> Message-ID: <545CF1E1.8000003@redhat.com> On 7.11.2014 17:20, Traiano Welcome wrote: > Hi Petr > > > > On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek wrote: >> On 7.11.2014 14:08, Traiano Welcome wrote: >>> Hi List >>> >>> I'm trying to configure a replica for a primary freeipa IdM server >>> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install" >>> fails with the following error: >>> -- >>> ipa-replica-install -d --setup-ca --setup-dns --no-forwarders >>> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >>> . >>> . >>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >>> IP network address >>> . >>> . >>> -- >>> >>> For context, here is the full output from the replica-install command (I've >>> attached the full debug output): >>> >>> --- >>> [root at lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns >>> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >>> WARNING: conflicting time&date synchronization service 'chronyd' will >>> be disabled in favor of ntpd >>> >>> Directory Manager (existing master) password: >>> >>> Run connection check to master >>> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': >>> Directory Service: Unsecure port (389): OK >>> Directory Service: Secure port (636): OK >>> Kerberos KDC: TCP (88): OK >>> Kerberos Kpasswd: TCP (464): OK >>> HTTP Server: Unsecure port (80): OK >>> HTTP Server: Secure port (443): OK >>> >>> The following list of ports use UDP protocol and would need to be >>> checked manually: >>> Kerberos KDC: UDP (88): SKIPPED >>> Kerberos Kpasswd: UDP (464): SKIPPED >>> >>> Connection from replica to master is OK. >>> Start listening on required ports for remote master check >>> Get credentials to log in to remote master >>> admin at IDM.LOCAL password: >>> >>> Check SSH connection to remote master >>> Execute check on remote master >>> Check connection from master to remote replica 'lolpr-idm-slve.idm.local': >>> Directory Service: Unsecure port (389): OK >>> Directory Service: Secure port (636): OK >>> Kerberos KDC: TCP (88): OK >>> Kerberos KDC: UDP (88): OK >>> Kerberos Kpasswd: TCP (464): OK >>> Kerberos Kpasswd: UDP (464): OK >>> HTTP Server: Unsecure port (80): OK >>> HTTP Server: Secure port (443): OK >>> >>> Connection from master to replica is OK. >>> >>> Connection check OK >>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >>> IP network address >>> [root at lolpr-idm-slve ipa]# >>> >>> --- >>> >>> Some things I've tested: >>> >>> 1. disable selinux (followed by reboot) - no change >>> 2. disable IPv6 (followed by reboot) - no change >>> >>> DNS resolution and IP checks seem fine: >>> --- >>> >>> [root at lolpr-idm-slve install]# hostname >>> lolpr-idm-slve.idm.local >>> >>> >>> [root at lolpr-idm-slve install]# ifconfig >>> ens192: flags=4163 mtu 1500 >>> inet 172.16.100.222 netmask 255.255.255.255 broadcast >>> 172.16.100.222 >> >> This is the cause: IP address on ens192 interface is 172.16.100.222/32. >> >> What is your environment? Is it some kind of weird container? >> >> Is it even valid configuration? :-) I don't recall any use case for 32-bit >> netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point >> to point links. >> > > > AFAIK, a /32 netmask designates a single address. Should be valid, > although I'm not sure how IPA's installutils.py handles that. ipcalc > says: > > ---- > root at lol-dev:/opt/automation# ipcalc 172.16.100.222/32 > Address: 172.16.100.222 10101100.00010000.01100100.11011110 > Netmask: 255.255.255.255 = 32 11111111.11111111.11111111.11111111 > Wildcard: 0.0.0.0 00000000.00000000.00000000.00000000 > => > Hostroute: 172.16.100.222 10101100.00010000.01100100.11011110 > Hosts/Net: 1 Class B, Private Internet > ---- > > Nice reference, seems to confirm this is a single host: > http://www.oav.net/mirrors/cidr.html Sure, but how you can communicate using this address? You need to assign an address to the other end too :-) It is still unclear to me what is your use case. Petr^2 Spacek >> >>> ether 00:50:56:9c:1e:60 txqueuelen 1000 (Ethernet) >>> RX packets 17964 bytes 1705674 (1.6 MiB) >>> RX errors 0 dropped 10 overruns 0 frame 0 >>> TX packets 3772 bytes 595134 (581.1 KiB) >>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>> -- >>> >>> /etc/hosts looks like this: >>> >>> -- >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> 172.16.100.68 lolpr-idm-mstr.idm.local lolpr-idm-mstr >>> 172.16.100.222 lolpr-idm-slve.idm.local lolpr-idm-slve >>> 172.16.104.231 loltestdc001.loltestdc.com loltestdc001 >>> -- >>> >>> Host naming, forward and reverse resolution seems fine: >>> >>> --- >>> [root at lolpr-idm-slve install]# >>> [root at lolpr-idm-slve install]# host `hostname` >>> lolpr-idm-slve.idm.local has address 172.16.100.222 >>> [root at lolpr-idm-slve install]# >>> [root at lolpr-idm-slve install]# host `hostname`^C >>> [root at lolpr-idm-slve install]# host `hostname`| cut -d " " -f 4| xargs >>> -Iname host name >>> 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local. >>> [root at lolpr-idm-slve install]# >>> --- >>> >>> I'd be thankful if anyone could shed a light on why this error is happening >>> and point me in the direction of a fix. From traiano at gmail.com Fri Nov 7 17:10:09 2014 From: traiano at gmail.com (Traiano Welcome) Date: Fri, 7 Nov 2014 20:10:09 +0300 Subject: [Freeipa-users] The ipa-replica-install command failed, exception: SystemExit: Invalid IP Address ... Cannot use IP network address In-Reply-To: <545CF1E1.8000003@redhat.com> References: <545CE2ED.7020309@redhat.com> <545CF1E1.8000003@redhat.com> Message-ID: On Fri, Nov 7, 2014 at 7:22 PM, Petr Spacek wrote: > On 7.11.2014 17:20, Traiano Welcome wrote: >> Hi Petr >> >> >> >> On Fri, Nov 7, 2014 at 6:19 PM, Petr Spacek wrote: >>> On 7.11.2014 14:08, Traiano Welcome wrote: >>>> Hi List >>>> >>>> I'm trying to configure a replica for a primary freeipa IdM server >>>> (both CentOS 7, AD trusts configured on primary), but "ipa-replica-install" >>>> fails with the following error: >>>> -- >>>> ipa-replica-install -d --setup-ca --setup-dns --no-forwarders >>>> /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >>>> . >>>> . >>>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >>>> IP network address >>>> . >>>> . >>>> -- >>>> >>>> For context, here is the full output from the replica-install command (I've >>>> attached the full debug output): >>>> >>>> --- >>>> [root at lolpr-idm-slve ipa]# ipa-replica-install --setup-ca --setup-dns >>>> --no-forwarders /var/lib/ipa/replica-info-lolpr-idm-slve.idm.local.gpg >>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>> be disabled in favor of ntpd >>>> >>>> Directory Manager (existing master) password: >>>> >>>> Run connection check to master >>>> Check connection from replica to remote master 'lolpr-idm-mstr.idm.local': >>>> Directory Service: Unsecure port (389): OK >>>> Directory Service: Secure port (636): OK >>>> Kerberos KDC: TCP (88): OK >>>> Kerberos Kpasswd: TCP (464): OK >>>> HTTP Server: Unsecure port (80): OK >>>> HTTP Server: Secure port (443): OK >>>> >>>> The following list of ports use UDP protocol and would need to be >>>> checked manually: >>>> Kerberos KDC: UDP (88): SKIPPED >>>> Kerberos Kpasswd: UDP (464): SKIPPED >>>> >>>> Connection from replica to master is OK. >>>> Start listening on required ports for remote master check >>>> Get credentials to log in to remote master >>>> admin at IDM.LOCAL password: >>>> >>>> Check SSH connection to remote master >>>> Execute check on remote master >>>> Check connection from master to remote replica 'lolpr-idm-slve.idm.local': >>>> Directory Service: Unsecure port (389): OK >>>> Directory Service: Secure port (636): OK >>>> Kerberos KDC: TCP (88): OK >>>> Kerberos KDC: UDP (88): OK >>>> Kerberos Kpasswd: TCP (464): OK >>>> Kerberos Kpasswd: UDP (464): OK >>>> HTTP Server: Unsecure port (80): OK >>>> HTTP Server: Secure port (443): OK >>>> >>>> Connection from master to replica is OK. >>>> >>>> Connection check OK >>>> Invalid IP Address 172.16.100.222 for lolpr-idm-slve.idm.local: cannot use >>>> IP network address >>>> [root at lolpr-idm-slve ipa]# >>>> >>>> --- >>>> >>>> Some things I've tested: >>>> >>>> 1. disable selinux (followed by reboot) - no change >>>> 2. disable IPv6 (followed by reboot) - no change >>>> >>>> DNS resolution and IP checks seem fine: >>>> --- >>>> >>>> [root at lolpr-idm-slve install]# hostname >>>> lolpr-idm-slve.idm.local >>>> >>>> >>>> [root at lolpr-idm-slve install]# ifconfig >>>> ens192: flags=4163 mtu 1500 >>>> inet 172.16.100.222 netmask 255.255.255.255 broadcast >>>> 172.16.100.222 >>> >>> This is the cause: IP address on ens192 interface is 172.16.100.222/32. >>> >>> What is your environment? Is it some kind of weird container? >>> >>> Is it even valid configuration? :-) I don't recall any use case for 32-bit >>> netmask. As far as I remember 31-bit netmask is allowed by RFC 3021 for point >>> to point links. >>> >> >> >> AFAIK, a /32 netmask designates a single address. Should be valid, >> although I'm not sure how IPA's installutils.py handles that. ipcalc >> says: >> >> ---- >> root at lol-dev:/opt/automation# ipcalc 172.16.100.222/32 >> Address: 172.16.100.222 10101100.00010000.01100100.11011110 >> Netmask: 255.255.255.255 = 32 11111111.11111111.11111111.11111111 >> Wildcard: 0.0.0.0 00000000.00000000.00000000.00000000 >> => >> Hostroute: 172.16.100.222 10101100.00010000.01100100.11011110 >> Hosts/Net: 1 Class B, Private Internet >> ---- >> >> Nice reference, seems to confirm this is a single host: >> http://www.oav.net/mirrors/cidr.html > > Sure, but how you can communicate using this address? You need to assign an > address to the other end too :-) Doh! Thanks a ton, Petr. Time for me to lay off the coffee :-) > > It is still unclear to me what is your use case. > Simply to have a replica IdM server for clients to failover to should the primary IdM server be unreachable. Which is working wonderfully now ... > Petr^2 Spacek > >>> >>>> ether 00:50:56:9c:1e:60 txqueuelen 1000 (Ethernet) >>>> RX packets 17964 bytes 1705674 (1.6 MiB) >>>> RX errors 0 dropped 10 overruns 0 frame 0 >>>> TX packets 3772 bytes 595134 (581.1 KiB) >>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>>> -- >>>> >>>> /etc/hosts looks like this: >>>> >>>> -- >>>> 127.0.0.1 localhost localhost.localdomain localhost4 >>>> localhost4.localdomain4 >>>> 172.16.100.68 lolpr-idm-mstr.idm.local lolpr-idm-mstr >>>> 172.16.100.222 lolpr-idm-slve.idm.local lolpr-idm-slve >>>> 172.16.104.231 loltestdc001.loltestdc.com loltestdc001 >>>> -- >>>> >>>> Host naming, forward and reverse resolution seems fine: >>>> >>>> --- >>>> [root at lolpr-idm-slve install]# >>>> [root at lolpr-idm-slve install]# host `hostname` >>>> lolpr-idm-slve.idm.local has address 172.16.100.222 >>>> [root at lolpr-idm-slve install]# >>>> [root at lolpr-idm-slve install]# host `hostname`^C >>>> [root at lolpr-idm-slve install]# host `hostname`| cut -d " " -f 4| xargs >>>> -Iname host name >>>> 222.100.16.172.in-addr.arpa domain name pointer lolpr-idm-slve.idm.local. >>>> [root at lolpr-idm-slve install]# >>>> --- >>>> >>>> I'd be thankful if anyone could shed a light on why this error is happening >>>> and point me in the direction of a fix. From dpal at redhat.com Fri Nov 7 20:28:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Nov 2014 15:28:41 -0500 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> Message-ID: <545D2B79.7000200@redhat.com> On 11/07/2014 01:24 AM, Will Sheldon wrote: > On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com > ) wrote: >> On 11/07/2014 12:18 AM, Will Sheldon wrote: >>> >>> Hello all :) >>> >>> On the whole we are loving FreeIPA, Many thanks and much respect to >>> all involved, we?ve had a great 12-18 months hassle free use out of >>> it - it is a fantastically stable trouble free solution? however >>> now we?ve run into a small issue we (as mere mortals) are finding it >>> hard to resolve :-/ >>> >>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything >>> seems to go well, but one server is behaving oddly. It?s likely not >>> an IPA issue, it also reset it?s hostname somehow after the upgrade >>> (it?s an image in an openstack environment) >>> >>> If anyone has any pointers as to how to debug I?d be hugely >>> appreciative :) >>> >>> Two servers, server1.domain.com and server2.domain.com >>> >>> Server1 can?t push data to server2, there are updates and new >>> records on server1 that do not exist on server2. >>> >>> >>> from the logs on server1: >>> >>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >>> send endReplication extended operation (Can't contact LDAP server) >>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToserver2.domain.com" (server2:389): Replication bind >>> with GSSAPI auth resumed >>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >>> replicate schema: rc=2 >>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to >>> replay change (uniqueid (null), CSN (null)): Can't contact LDAP >>> server(-1). Will retry later. >> >> Try to see >> a) Server 1 properly resolves server 2 >> b) You can connect from server 1 to server 2 using ldapsearch >> c) your firewall has proper ports open >> d) dirserver on server 2 is actually running > > All seems working: > > [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base > -b '' namingContexts Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y switch? Did you find anything in the server2 logs? > # extended LDIF > # > # LDAPv3 > # base <> with scope baseObject > # filter: (objectclass=*) > # requesting: namingContexts > # > > # > dn: > namingContexts: dc=domain,dc=com > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at server1 ~]# > > And: > > [root at server2 ~]# /etc/init.d/dirsrv status > dirsrv DOMAIN-COM (pid 1009) is running... > dirsrv PKI-IPA (pid 1083) is running... > [root at server2 ~]# > > > >> >> >> Check logs on server 2 to see whether it actually sees an attempt to >> connect, I suspect not, so it is most likely a DNS/FW issue or dir >> server is not running on 2. >>> >>> >>> and the servers: >>> >>> [root at server1 ~]# ipa-replica-manage list -v `hostname` >>> Directory Manager password: >>> >>> server2.domain.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 0 Replica acquired successfully: Incremental >>> update started >>> last update ended: 2014-11-07 01:35:58+00:00 >>> [root at server1 ~]# >>> >>> >>> >>> [root at server2 ~]# ipa-replica-manage list -v `hostname` >>> Directory Manager password: >>> >>> server1.domain.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 0 Replica acquired successfully: Incremental >>> update succeeded >>> last update ended: 2014-11-07 01:35:43+00:00 >>> [root at server2 ~]# >>> >>> >>> >>> >>> Will Sheldon >>> >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> -- >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at atcri.com Fri Nov 7 23:16:49 2014 From: andy at atcri.com (Andrew Powell) Date: Fri, 07 Nov 2014 17:16:49 -0600 Subject: [Freeipa-users] DNS and $GENERATE Directive Message-ID: <545D52E1.3060005@atcri.com> Is there a way to add a Bind $GENERATE directive line to FreeIPA to automatically name DHCP-assigned ranges? In a file-based Bind installation, I can have the following line in the forward example.com zone file: $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$ (which adds records wd080.example.com thru wd250.example.com) And for the reverse zone (0.168.192.in-addr.arpa) I can have the following line: $generate 80-250/1 $ PTR wd${0,3,d}.example.com. I can do without naming the DHCP-assigned ranges, but it seems like the proper thing to do. From janellenicole80 at gmail.com Fri Nov 7 23:29:16 2014 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 07 Nov 2014 15:29:16 -0800 Subject: [Freeipa-users] tuning for DS? Message-ID: <545D55CC.3040800@gmail.com> hi all.. As we head into the weekend, I hope you all take time to play and enjoy. At the same time, if you are online and have any ideas - are there any good tuning suggestions for beefing up 389ds for an environment with approx 4000 users and approx 1000 hosts? My guess is the cache needs work for the number of users, so that is where I am looking. Any ideas? ~J From mlasevich at gmail.com Sat Nov 8 00:00:19 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Fri, 7 Nov 2014 16:00:19 -0800 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <20141107091831.GM14368@hendrix.brq.redhat.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> Message-ID: Exactly 16 hours after reboot the problem returned on both servers. What has a 16 hour timeout? I set log level to 10 and got some logs, but they are long and not sure what I am looking for. I am attaching some logs ( out of sheer paranoia I have slightly sanitized them, 1.1.1.2 is the secondary IPA server, username at MY.DOMAIN.COM is the principle and endserver.my.domain.com is the IPA client this is happening on) On Fri, Nov 7, 2014 at 1:18 AM, Jakub Hrozek wrote: > On Thu, Nov 06, 2014 at 09:33:35PM -0800, Michael Lasevich wrote: > > For what its worth, my issue was resolved when I rebooted the server. > > > > Restarting sssd and/or clearing it's cache did not do it, but a full > reboot > > seems to have done it. Something much have been cached or some temp file > I > > missed. Will need to look into it further as I have a number of servers > yet > > to be upgraded and having to reboot linux servers to do an upgrade seem > > sacrilegious... > > We need to see the krb5_child.log file ideally with a very high > debug_level (10 would enable KRB5_TRACE debugging as well..) > > > > > -M > > > > On Thu, Nov 6, 2014 at 9:26 PM, David Taylor > > > wrote: > > > > > As an add on, I?ve upgraded our Xen template to 6.6 and run up a new > VM > > > using that and it attaches to the IPA environment perfectly well, so > I?m > > > guessing it is an issue with the upgrade scripts. > > > > > > > > > > > > > > > > > > Best regards > > > > > > *David Taylor* > > > > > > *From:* Michael Lasevich [mailto:mlasevich at gmail.com] > > > *Sent:* Friday, 7 November 2014 4:00 PM > > > *To:* Jakub Hrozek > > > *Cc:* David Taylor; freeipa-users at redhat.com > > > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade to > > > 6.6 > > > > > > > > > > > > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to > 1.11 > > > (centos 6.5 to 6.6) > > > > > > > > > > > > I seem to be able to log in via ssh, but when I use http pam service, I > > > get inconsistent behavior - seems like sometimes it works and others it > > > errors out (success and failure can happen within a second) > > > > > > > > > > > > In the logs I see things like: > > > > > > > > > > > > [sssd[krb5_child[15410]]]: Internal credentials cache error > > > > > > and > > > > > > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= > > > user=username > > > received for user username: 4 (System error) > > > > > > Nothing in the audit.log that I can see > > > > > > I am guessing this is an sssd issue but I am hoping someone here knows > how > > > to deal with it. > > > > > > IN case it matters - here is the pam config: > > > > > > auth required pam_env.so > > > auth sufficient pam_sss.so > > > auth required pam_deny.so > > > > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > account required pam_permit.so > > > > > > password requisite pam_cracklib.so try_first_pass retry=3 type= > > > password sufficient pam_sss.so use_authtok > > > password required pam_deny.so > > > > > > > > > > > > session optional pam_keyinit.so revoke > > > session required pam_limits.so > > > session optional pam_oddjob_mkhomedir.so > > > session [success=1 default=ignore] pam_succeed_if.so service in > crond > > > quiet use_uid > > > session optional pam_sss.so > > > > > > -M > > > > > > > > > > > > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek > wrote: > > > > > > On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: > > > > Thanks for the reply. The PAM file is pretty stock for a centos build > > > > > > > > #%PAM-1.0 > > > > # This file is auto-generated. > > > > # User changes will be destroyed the next time authconfig is run. > > > > auth required pam_env.so > > > > auth sufficient pam_unix.so nullok try_first_pass > > > > auth requisite pam_succeed_if.so uid >= 500 quiet > > > > auth sufficient pam_sss.so use_first_pass > > > > auth required pam_deny.so > > > > > > > > account required pam_unix.so > > > > account sufficient pam_localuser.so > > > > account sufficient pam_succeed_if.so uid < 500 quiet > > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so > > > > account required pam_permit.so > > > > > > > > password requisite pam_cracklib.so try_first_pass retry=3 > type= > > > > password sufficient pam_unix.so sha512 shadow nullok > > > try_first_pass use_authtok > > > > password sufficient pam_sss.so use_authtok > > > > password required pam_deny.so > > > > > > > > session optional pam_keyinit.so revoke > > > > session required pam_limits.so > > > > session [success=1 default=ignore] pam_succeed_if.so service in > > > crond quiet use_uid > > > > session required pam_unix.so > > > > session optional pam_sss.so > > > > > > > > > > > > Best regards > > > > David Taylor > > > > > > OK, so pam_sss is there ... > > > > > > And yet you see no mention of pam_sss.so in /var/log/secure ? > > > > > > Is this the file that was included from the service-specific PAM > > > 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 > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: krb5_child.log Type: application/octet-stream Size: 364993 bytes Desc: not available URL: From dpal at redhat.com Sat Nov 8 00:44:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Nov 2014 19:44:00 -0500 Subject: [Freeipa-users] tuning for DS? In-Reply-To: <545D55CC.3040800@gmail.com> References: <545D55CC.3040800@gmail.com> Message-ID: <545D6750.3070809@redhat.com> On 11/07/2014 06:29 PM, Janelle wrote: > hi all.. > > As we head into the weekend, I hope you all take time to play and > enjoy. At the same time, if you are online and have any ideas - are > there any good tuning suggestions for beefing up 389ds for an > environment with approx 4000 users and approx 1000 hosts? > > My guess is the cache needs work for the number of users, so that is > where I am looking. Any ideas? > > ~J > http://www.port389.org/docs/389ds/FAQ/performance-tuning.html#linux I would start there. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From diaulas at gmail.com Sat Nov 8 14:24:50 2014 From: diaulas at gmail.com (Diaulas Castro) Date: Sat, 8 Nov 2014 12:24:50 -0200 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> Message-ID: We have similar issue but on RHEL 6.6 (sssd 1.11), the problem is about enumerating groups. Use the command "id some_group_that_user_belong" on affected client, logout and try logon again. Our issue was with sudo not working, but everything based on groups stopped to work too. For workaround (if this is your problem too) edit sssd.con on domain section: enumarating = true 2014-11-07 22:00 GMT-02:00 Michael Lasevich : > Exactly 16 hours after reboot the problem returned on both servers. What > has a 16 hour timeout? > > I set log level to 10 and got some logs, but they are long and not sure > what I am looking for. I am attaching some logs ( out of sheer paranoia I > have slightly sanitized them, 1.1.1.2 is the secondary IPA server, > username at MY.DOMAIN.COM is the principle and endserver.my.domain.com is > the IPA client this is happening on) > > > > On Fri, Nov 7, 2014 at 1:18 AM, Jakub Hrozek wrote: > >> On Thu, Nov 06, 2014 at 09:33:35PM -0800, Michael Lasevich wrote: >> > For what its worth, my issue was resolved when I rebooted the server. >> > >> > Restarting sssd and/or clearing it's cache did not do it, but a full >> reboot >> > seems to have done it. Something much have been cached or some temp >> file I >> > missed. Will need to look into it further as I have a number of servers >> yet >> > to be upgraded and having to reboot linux servers to do an upgrade seem >> > sacrilegious... >> >> We need to see the krb5_child.log file ideally with a very high >> debug_level (10 would enable KRB5_TRACE debugging as well..) >> >> > >> > -M >> > >> > On Thu, Nov 6, 2014 at 9:26 PM, David Taylor < >> david.taylor at speedcast.com> >> > wrote: >> > >> > > As an add on, I've upgraded our Xen template to 6.6 and run up a new >> VM >> > > using that and it attaches to the IPA environment perfectly well, so >> I'm >> > > guessing it is an issue with the upgrade scripts. >> > > >> > > >> > > >> > > >> > > >> > > Best regards >> > > >> > > *David Taylor* >> > > >> > > *From:* Michael Lasevich [mailto:mlasevich at gmail.com] >> > > *Sent:* Friday, 7 November 2014 4:00 PM >> > > *To:* Jakub Hrozek >> > > *Cc:* David Taylor; freeipa-users at redhat.com >> > > *Subject:* Re: [Freeipa-users] Centos IPA Client fails after upgrade >> to >> > > 6.6 >> > > >> > > >> > > >> > > I am seeing somewhat similar behavior once upgrading from sssd 1.9 to >> 1.11 >> > > (centos 6.5 to 6.6) >> > > >> > > >> > > >> > > I seem to be able to log in via ssh, but when I use http pam service, >> I >> > > get inconsistent behavior - seems like sometimes it works and others >> it >> > > errors out (success and failure can happen within a second) >> > > >> > > >> > > >> > > In the logs I see things like: >> > > >> > > >> > > >> > > [sssd[krb5_child[15410]]]: Internal credentials cache error >> > > >> > > and >> > > >> > > authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= >> > > user=username >> > > received for user username: 4 (System error) >> > > >> > > Nothing in the audit.log that I can see >> > > >> > > I am guessing this is an sssd issue but I am hoping someone here >> knows how >> > > to deal with it. >> > > >> > > IN case it matters - here is the pam config: >> > > >> > > auth required pam_env.so >> > > auth sufficient pam_sss.so >> > > auth required pam_deny.so >> > > >> > > account [default=bad success=ok user_unknown=ignore] pam_sss.so >> > > account required pam_permit.so >> > > >> > > password requisite pam_cracklib.so try_first_pass retry=3 type= >> > > password sufficient pam_sss.so use_authtok >> > > password required pam_deny.so >> > > >> > > >> > > >> > > session optional pam_keyinit.so revoke >> > > session required pam_limits.so >> > > session optional pam_oddjob_mkhomedir.so >> > > session [success=1 default=ignore] pam_succeed_if.so service in >> crond >> > > quiet use_uid >> > > session optional pam_sss.so >> > > >> > > -M >> > > >> > > >> > > >> > > On Wed, Nov 5, 2014 at 1:05 AM, Jakub Hrozek >> wrote: >> > > >> > > On Wed, Nov 05, 2014 at 02:30:55AM +0000, David Taylor wrote: >> > > > Thanks for the reply. The PAM file is pretty stock for a centos >> build >> > > > >> > > > #%PAM-1.0 >> > > > # This file is auto-generated. >> > > > # User changes will be destroyed the next time authconfig is run. >> > > > auth required pam_env.so >> > > > auth sufficient pam_unix.so nullok try_first_pass >> > > > auth requisite pam_succeed_if.so uid >= 500 quiet >> > > > auth sufficient pam_sss.so use_first_pass >> > > > auth required pam_deny.so >> > > > >> > > > account required pam_unix.so >> > > > account sufficient pam_localuser.so >> > > > account sufficient pam_succeed_if.so uid < 500 quiet >> > > > account [default=bad success=ok user_unknown=ignore] pam_sss.so >> > > > account required pam_permit.so >> > > > >> > > > password requisite pam_cracklib.so try_first_pass retry=3 >> type= >> > > > password sufficient pam_unix.so sha512 shadow nullok >> > > try_first_pass use_authtok >> > > > password sufficient pam_sss.so use_authtok >> > > > password required pam_deny.so >> > > > >> > > > session optional pam_keyinit.so revoke >> > > > session required pam_limits.so >> > > > session [success=1 default=ignore] pam_succeed_if.so service in >> > > crond quiet use_uid >> > > > session required pam_unix.so >> > > > session optional pam_sss.so >> > > > >> > > > >> > > > Best regards >> > > > David Taylor >> > > >> > > OK, so pam_sss is there ... >> > > >> > > And yet you see no mention of pam_sss.so in /var/log/secure ? >> > > >> > > Is this the file that was included from the service-specific PAM >> > > 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 >> > > >> > > >> > > >> > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Nov 8 16:44:51 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 8 Nov 2014 17:44:51 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> Message-ID: <20141108164450.GB19510@mail.corp.redhat.com> On (08/11/14 12:24), Diaulas Castro wrote: >We have similar issue but on RHEL 6.6 (sssd 1.11), the problem is about >enumerating groups. > Diaulas, Have you reported your problem? I know just about one problem with IPA and sssd-1.11 (on RHEL 6.6) The upstream bug is https://fedorahosted.org/sssd/ticket/2471 There is a workaround. You can change value of option ldap_group_object_class in domain section to ipaUserGroup ldap_group_object_class = ipaUserGroup Could you confirm that you had the same problem? Otherwise please report bug either to upstream trac or Red Had Bugzilla. >Use the command "id some_group_that_user_belong" on affected client, logout >and try logon again. > >Our issue was with sudo not working, but everything based on groups stopped >to work too. > >For workaround (if this is your problem too) edit sssd.con on domain >section: >enumarating = true It would be better to fix it in sssd. LS From rmeggins at redhat.com Sat Nov 8 23:47:05 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Sat, 08 Nov 2014 17:47:05 -0600 Subject: [Freeipa-users] tuning for DS? In-Reply-To: <545D6750.3070809@redhat.com> References: <545D55CC.3040800@gmail.com> <545D6750.3070809@redhat.com> Message-ID: <545EAB79.5010503@redhat.com> On 11/07/2014 06:44 PM, Dmitri Pal wrote: > On 11/07/2014 06:29 PM, Janelle wrote: >> hi all.. >> >> As we head into the weekend, I hope you all take time to play and >> enjoy. At the same time, if you are online and have any ideas - are >> there any good tuning suggestions for beefing up 389ds for an >> environment with approx 4000 users and approx 1000 hosts? >> >> My guess is the cache needs work for the number of users, so that is >> where I am looking. Any ideas? >> >> ~J >> > http://www.port389.org/docs/389ds/FAQ/performance-tuning.html#linux > > I would start there. > For cache tuning (entry cache, dn cache, db cache) see https://github.com/richm/scripts/wiki/dbmon.sh (dbmon.sh might also be in your 389-ds-base package depending on the platform) From bill at pecknet.com Sun Nov 9 21:48:28 2014 From: bill at pecknet.com (Bill Peck) Date: Sun, 9 Nov 2014 16:48:28 -0500 Subject: [Freeipa-users] missing package in 4.1.1 repo In-Reply-To: <20141106165614.GZ4107@redhat.com> References: <20141106164701.GY4107@redhat.com> <20141106165614.GZ4107@redhat.com> Message-ID: I'm still not able to install freeipa-server-4.1.1 on centos7.. Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) Requires: jackson-jaxrs-json-provider Any ideas? Thanks for providing this. On Thu, Nov 6, 2014 at 11:56 AM, Alexander Bokovoy wrote: > On Thu, 06 Nov 2014, Alexander Bokovoy wrote: > >> On Thu, 06 Nov 2014, Rob Verduijn wrote: >> >>> Hi, >>> >>> There is a dependency error in the updated repo. >>> I did a yum clean all >>> then a yum update. >>> >>> I got this error: >>> Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) >>> Requires: slapi-nis >= 0.54.1-1 >>> Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) >>> slapi-nis = 0.52-1.fc20 >>> Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) >>> slapi-nis = 0.54-1.fc20 >>> Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) >>> slapi-nis = 0.50-1.fc20 >>> >>> >>> yum list --show-duplicates slapi-nis >>> Installed Packages >>> slapi-nis.x86_64 0.54-1.fc20 >>> @mkosek-freeipa >>> Available Packages >>> slapi-nis.x86_64 0.50-1.fc20 >>> private.base >>> slapi-nis.x86_64 0.52-1.fc20 >>> private.updates >>> slapi-nis.x86_64 0.54-1.fc20 >>> mkosek-freeipa >>> >>> there is no 0.54.1-1.fc20 version of slapi-nis >>> >> It is being rebuilt as we speak. >> https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ >> > Done and should be available. > > -- > / 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Mon Nov 10 01:05:36 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Sun, 9 Nov 2014 17:05:36 -0800 Subject: [Freeipa-users] Free ipa Configurations Message-ID: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> Hello I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. another question is I've tried using 4.1.0 for the server side but I can't configure the dns forwarders for it it always says that the forwarder does not respond, How can I solve this too? is there a new way to add a dns forwarder for IPA ?? please help me with these freeipa problems because I really want to deploy them already and get it over with -_- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dns.png Type: image/png Size: 54072 bytes Desc: not available URL: From tlau at tetrioncapital.com Mon Nov 10 05:14:38 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Mon, 10 Nov 2014 13:14:38 +0800 Subject: [Freeipa-users] Apache WebDav file sharing permission problem Message-ID: Hi All, I am successfully letting Apache auth against FreeIPA, but whatever folder/files being created on WebDav server would be using Apache user and group instead of login user/group, does anyone know how to fix this? Kerberos + LDAP config: http://pastebin.com/zpP3TEst -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Nov 10 06:46:16 2014 From: Less at imagine-sw.com (Les Stott) Date: Mon, 10 Nov 2014 06:46:16 +0000 Subject: [Freeipa-users] trouble with ldap authentication for a Cisco UCS 5108 Message-ID: <4ED173A868981548967B4FCA2707222628021A09@AACMBXP04.exchserver.com> Hi all, I have a FreeIPA environment with standard rhel6 package sets. Everything is working well. I would like to get our Cisco UCS 5108 authenticating via ldap with TLS using ldap group based checks. The ucs manager runs the latest 2.2(3a) Currently I have it authenticating via radius (which auth's to the ldap server in freeipa), but the radius setup doesn't allow for more fine grained group access controls. I've tried may things to get ldap to work, but failing miserably. According to the doc's it should be fairly straight forward (I wish it was!). Has anyone got a Cisco UCS device to be able to authenticate successfully using LDAP over TLS with FreeIPA? I'd appreciate any feedback so I know whether it is actually possible or not. Thanks, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Nov 10 07:34:57 2014 From: Less at imagine-sw.com (Les Stott) Date: Mon, 10 Nov 2014 07:34:57 +0000 Subject: [Freeipa-users] restored replica ssl issue Message-ID: <4ED173A868981548967B4FCA2707222628021BE5@AACMBXP04.exchserver.com> Hi all, I have a standard freeipa environment under rhel6. One of my replica servers, lets call it "serverB" had issues and I eventually rebuilt it. I rebuilt and restored data, but something wasn't right. Replication wasn't working. I had tried to re-initialize replication but it didn't help. The last thing I did was to .... On serverB ipa-server-install --uninstall getcert list # remove the cert from being tracked (as per info shown after completion of ipa-server-install --uninstall getcert stop-tracking -i 20131216070540 rm /var/lib/ipa/replica-info-serverB.mydomain.com.gpg On server (the master) ipa host-del serverB.mydomain.com.gpg ipa-replica-manage del serverB.mydomain.com.gpg --force cd /var/lib/ipa rm replica-info- serverB.mydomain.com.gpg This all appeared fine, and seemingly removes serverB completely. So, I then set it back up as a replica in the normal way ,and this worked well. Replication is working and all looks good except for the FreeIPA Web interface. When I try to browse to https://serverB.mydomain.com/ipa/ui/ I get "unknown Error" in a popup box. In the apache error log I see.... [Mon Nov 10 02:08:37 2014] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate I am not sure what "Peer" references - serverB locally? My gut feel is that perhaps there were leftover remnants (possibly in ipa httpd config) from after the uninstall and the reinstall didn't overwrite them.. Can anyone shed any light on the error above? Thanks in advance, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Nov 10 08:25:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 09:25:08 +0100 Subject: [Freeipa-users] DNS and $GENERATE Directive In-Reply-To: <545D52E1.3060005@atcri.com> References: <545D52E1.3060005@atcri.com> Message-ID: <54607664.5070206@redhat.com> On 11/08/2014 12:16 AM, Andrew Powell wrote: > Is there a way to add a Bind $GENERATE directive line to FreeIPA to > automatically name DHCP-assigned ranges? > > In a file-based Bind installation, I can have the following line in the forward > example.com zone file: > > $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$ > > (which adds records wd080.example.com thru wd250.example.com) > > And for the reverse zone (0.168.192.in-addr.arpa) I can have the following line: > > $generate 80-250/1 $ PTR wd${0,3,d}.example.com. > > I can do without naming the DHCP-assigned ranges, but it seems like the proper > thing to do. > Interesting question. I do not think bind-dyndb-ldap supports the $GENERATE directive. I am not even sure how to extend LDAP DNS tree to support it as it has a very specific syntax. You would need to add a new LDAP space accepting strings that would be then passed to BIND... I will let Petr to assess if this is possible or not. For now, the best approach would be to either add all these records to LDAP or to have it in a BIND zone file and synchronize between all FreeIPA DNS servers. Martin From mbasti at redhat.com Mon Nov 10 09:10:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Nov 2014 10:10:31 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> Message-ID: <54608107.4020202@redhat.com> On 10/11/14 02:05, Rolf Nufable wrote: > Hello > > I have tons of questions on why free ipa wont't work on my network , > I've been using fedora 20 as the os for the server and client free ipa . > > I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the > client side using 2 VM's at first it was okay, got it connected and > used ldap to pass sudo for the client side, but when I finally > deployed it in our real network consisting of an esxi server and one > work station having the same versions of free ipa for server and > client, the error that I'm getting is that " the user does not exist " > when I invoked the " su - ( user ) " command, so My question is how > can I solve this problem?? I've been at it for 3 weeks now .. > > another question is I've tried using 4.1.0 for the server side but I > can't configure the dns forwarders for it it always says that the > forwarder does not respond, How can I solve this too? is there a new > way to add a dns forwarder for IPA ?? > > please help me with these freeipa problems because I really want to > deploy them already and get it over with -_- > > Hello, IPA (4.1) doesn't allow to add global forwarders, which are not responding during installation. Are you sure the forwarder is working? Can you resolve root zone using this forwarder? Workaround is to install server without --forwarder option, after installation you can add global forwarder using command dnsconfig-mod --forwarder=a.b.c.d HTH Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From diaulas at gmail.com Mon Nov 10 10:04:04 2014 From: diaulas at gmail.com (Diaulas Castro) Date: Mon, 10 Nov 2014 08:04:04 -0200 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <20141108164450.GB19510@mail.corp.redhat.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> <20141108164450.GB19510@mail.corp.redhat.com> Message-ID: Hi Lukas, Already opened case within Red Hat. They told on case there is "private" bugzilla for this "known" problem, the case got closed. Im on vacation and RH Customer Portal seems off right now, cant find if got the case got updated or there is errata for this issue. 2014-11-08 14:44 GMT-02:00 Lukas Slebodnik : > On (08/11/14 12:24), Diaulas Castro wrote: > >We have similar issue but on RHEL 6.6 (sssd 1.11), the problem is about > >enumerating groups. > > > Diaulas, > Have you reported your problem? > > I know just about one problem with IPA and sssd-1.11 (on RHEL 6.6) > The upstream bug is https://fedorahosted.org/sssd/ticket/2471 > > There is a workaround. You can change value of option > ldap_group_object_class > in domain section to ipaUserGroup > > ldap_group_object_class = ipaUserGroup > > Could you confirm that you had the same problem? > Otherwise please report bug either to upstream trac or Red Had Bugzilla. > > >Use the command "id some_group_that_user_belong" on affected client, > logout > >and try logon again. > > > >Our issue was with sudo not working, but everything based on groups > stopped > >to work too. > > > >For workaround (if this is your problem too) edit sssd.con on domain > >section: > >enumarating = true > It would be better to fix it in sssd. > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Nov 10 10:10:45 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Nov 2014 11:10:45 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> Message-ID: <20141110101045.GD5577@hendrix.brq.redhat.com> On Fri, Nov 07, 2014 at 04:00:19PM -0800, Michael Lasevich wrote: > Exactly 16 hours after reboot the problem returned on both servers. What > has a 16 hour timeout? > > I set log level to 10 and got some logs, but they are long and not sure > what I am looking for. I am attaching some logs ( out of sheer paranoia I > have slightly sanitized them, 1.1.1.2 is the secondary IPA server, > username at MY.DOMAIN.COM is the principle and endserver.my.domain.com is the > IPA client this is happening on) Thank you, I see some errors in the log: (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [get_and_save_tgt] (0x0020): 1021: [-1765328188][Internal credentials cache error] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [map_krb5_error] (0x0020): 1043: [-1765328188][Internal credentials cache error] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [pack_response_packet] (0x2000): response packet size: [20] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [main] (0x0400): krb5_child completed successfully The complete run for that particular process is: (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [main] (0x0400): krb5_child started. (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [unpack_buffer] (0x1000): total buffer size: [132] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [unpack_buffer] (0x0100): cmd [241] uid [241600006] gid [241600006] validate [true] enterprise principal [false] offline [false] UPN [username at MY.DOMAIN.COM] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_241600006_jgS4rv] keytab: [/etc/krb5.keytab] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/endserver.my.domain.com at MY.DOMAIN.COM] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/endserver.my.domain.com at MY.DOMAIN.COM in keytab. (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [match_principal] (0x1000): Principal matched to the sample (host/endserver.my.domain.com at MY.DOMAIN.COM). (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.988922: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM from FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM with result: 0/Success (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [main] (0x0400): Will perform online auth (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MY.DOMAIN.COM] (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.989029: Getting initial credentials for username at MY.DOMAIN.COM (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.989099: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.989173: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM\@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.989247: Sending request (190 bytes) to MY.DOMAIN.COM (Fri Nov 7 16:09:53 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401793.989534: Sending initial UDP request to dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2160: Received answer from dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2229: Response was from master KDC (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2258: Received error from KDC: -1765328359/Additional pre-authentication required (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2283: Upgrading to FAST due to presence of PA_FX_FAST in reply (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2300: Restarting to upgrade to FAST (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2320: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2390: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM\@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2414: Upgrading to FAST due to presence of PA_FX_FAST in reply (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2431: FAST armor ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2489: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM\@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not found (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2551: Getting credentials host/endserver.my.domain.com at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM using ccache FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2607: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM from FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM with result: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2643: Armor ccache sesion key: aes256-cts/CB2D (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2694: Creating authenticator for host/endserver.my.domain.com at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM, seqnum 0, subkey aes256-cts/73F3, session key aes256-cts/CB2D (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2774: FAST armor key: aes256-cts/581F (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2811: Encoding request body and padata into FAST request (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2885: Sending request (1092 bytes) to MY.DOMAIN.COM (master) (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.2978: Sending initial UDP request to dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7625: Received answer from dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7658: Received error from KDC: -1765328359/Additional pre-authentication required (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7672: Decoding FAST response (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7728: Processing preauth types: 136, 19, 138, 133, 137 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7748: Selected etype info: etype aes256-cts, salt "MY.DOMAIN.COMusername", params "" (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.7759: Received cookie: MIT (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.26210: Preauth module encrypted_challenge (138) (flags=1) returned: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.26229: Produced preauth for next request: 133, 138 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.26239: Encoding request body and padata into FAST request (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.26287: Sending request (1190 bytes) to MY.DOMAIN.COM (master) (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.26349: Sending initial UDP request to dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.46917: Received answer from dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.46954: Decoding FAST response (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47024: Processing preauth types: 19, 138 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47048: Selected etype info: etype aes256-cts, salt "MY.DOMAIN.COMusername", params "" (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47104: Preauth module encrypted_challenge (138) (flags=1) returned: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47124: Produced preauth for next request: (empty) (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47145: AS key determined by preauth: aes256-cts/33DF (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47184: FAST reply key: aes256-cts/1E4A (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47232: Decrypted AS reply; session key is: aes256-cts/6732 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47266: FAST negotiation: available (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [10357377] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [validate_tgt] (0x2000): Found keytab entry with the realm of the credential. (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47385: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47405: Resolving unique ccache of type MEMORY (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47430: Initializing MEMORY:YCZ1t6d with default princ username at MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47451: Removing username at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM from MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47495: Storing username at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM in MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47527: Getting credentials username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM using ccache MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47561: Retrieving username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM from MEMORY:YCZ1t6d with result: -1765328243/Matching credential not found (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47592: Retrieving username at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM from MEMORY:YCZ1t6d with result: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47613: Found cached TGT for service realm: username at MY.DOMAIN.COM -> krbtgt/MY.DOMAIN.COM at MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47630: Requesting tickets for host/endserver.my.domain.com at MY.DOMAIN.COM, referrals on (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47660: Generated subkey for TGS request: aes256-cts/4300 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47682: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47759: Sending request (761 bytes) to MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.47849: Sending initial UDP request to dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61746: Received answer from dgram 1.1.1.2:88 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61822: Response was from master KDC (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61893: TGS reply is for username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM with session key aes256-cts/61B8 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61931: TGS request result: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61960: Received creds for desired service host/endserver.my.domain.com at MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.61989: Removing username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM from MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62014: Storing username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM in MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62057: Creating authenticator for username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM, seqnum 0, subkey (null, session key aes256-cts/61B8 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62152: Retrieving host/endserver.my.domain.com at MY.DOMAIN.COM from FILE:/etc/krb5.keytab (vno 1, enctype aes256-cts) with result: 0/Success (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62213: Decrypted AP-REQ with specified server principal host/endserver.my.domain.com at MY.DOMAIN.COM: aes256-cts/AFF6 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62244: AP-REQ ticket: username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM, session key aes256-cts/61B8 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62456: Negotiated enctype based on authenticator: aes256-cts (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62510: Initializing MEMORY:rd_req2 with default princ username at MY.DOMAIN.COM (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62541: Removing username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM from MEMORY:rd_req2 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62567: Storing username at MY.DOMAIN.COM -> host/endserver.my.domain.com at MY.DOMAIN.COM in MEMORY:rd_req2 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62597: Destroying ccache MEMORY:YCZ1t6d (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [validate_tgt] (0x0400): TGT verified using key for [host/endserver.my.domain.com at MY.DOMAIN.COM]. (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_child_krb5_trace_cb] (0x4000): [13722] 1415401794.62666: Destroying ccache MEMORY:rd_req2 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [become_user] (0x0200): Trying to become user [241600006][241600006]. (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [FILE:/tmp/krb5cc_241600006_jgS4rv] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [sss_get_ccache_name_for_principal] (0x2000): krb5_cc_cache_match failed: [-1765328243][Can't find client principal username at MY.DOMAIN.COM in cache collection] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [create_ccache] (0x4000): Initializing ccache of type [FILE] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [get_and_save_tgt] (0x0020): 1021: [-1765328188][Internal credentials cache error] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [map_krb5_error] (0x0020): 1043: [-1765328188][Internal credentials cache error] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [pack_response_packet] (0x2000): response packet size: [20] (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 7 16:09:54 2014) [[sssd[krb5_child[13722]]]] [main] (0x0400): krb5_child completed successfully So according to the logs, the create_ccache() function failed. Unfortunately, we don't do very good job at logging the failures there.. Michael, are you able to run a custom package with extra debugging? It would help us pinpoint which line actually is failing. Thanks a lot for providing the logs! From mkosek at redhat.com Mon Nov 10 11:39:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 12:39:31 +0100 Subject: [Freeipa-users] missing package in 4.1.1 repo In-Reply-To: References: <20141106164701.GY4107@redhat.com> <20141106165614.GZ4107@redhat.com> Message-ID: <5460A3F3.8050208@redhat.com> This is a new dependency that PKI/dogtag grew with latest version bump. It is not available in the mkosek/freeipa repo, but we will give it a shot in providing it (and it's dependencies) in the repo ourselves and also parallely ask dogtag team to help. Obviously, this does scale well, Java dependencies are tricky to be maintained by the FreeIPA team itself. I started freeipa-devel discussion about Copr repos so hopefully we get to a more sustainable solution for a long term. Martin On 11/09/2014 10:48 PM, Bill Peck wrote: > I'm still not able to install freeipa-server-4.1.1 on centos7.. > > Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) > Requires: jackson-jaxrs-json-provider > > Any ideas? > > Thanks for providing this. > > On Thu, Nov 6, 2014 at 11:56 AM, Alexander Bokovoy > wrote: > >> On Thu, 06 Nov 2014, Alexander Bokovoy wrote: >> >>> On Thu, 06 Nov 2014, Rob Verduijn wrote: >>> >>>> Hi, >>>> >>>> There is a dependency error in the updated repo. >>>> I did a yum clean all >>>> then a yum update. >>>> >>>> I got this error: >>>> Error: Package: freeipa-server-4.1.1-1.fc20.x86_64 (mkosek-freeipa) >>>> Requires: slapi-nis >= 0.54.1-1 >>>> Removing: slapi-nis-0.52-1.fc20.x86_64 (@private.updates) >>>> slapi-nis = 0.52-1.fc20 >>>> Updated By: slapi-nis-0.54-1.fc20.x86_64 (mkosek-freeipa) >>>> slapi-nis = 0.54-1.fc20 >>>> Available: slapi-nis-0.50-1.fc20.x86_64 (fedora) >>>> slapi-nis = 0.50-1.fc20 >>>> >>>> >>>> yum list --show-duplicates slapi-nis >>>> Installed Packages >>>> slapi-nis.x86_64 0.54-1.fc20 >>>> @mkosek-freeipa >>>> Available Packages >>>> slapi-nis.x86_64 0.50-1.fc20 >>>> private.base >>>> slapi-nis.x86_64 0.52-1.fc20 >>>> private.updates >>>> slapi-nis.x86_64 0.54-1.fc20 >>>> mkosek-freeipa >>>> >>>> there is no 0.54.1-1.fc20 version of slapi-nis >>>> >>> It is being rebuilt as we speak. >>> https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/57344/ >>> >> Done and should be available. >> >> -- >> / 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 >> > > > From mkosek at redhat.com Mon Nov 10 11:42:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 12:42:45 +0100 Subject: [Freeipa-users] trouble with ldap authentication for a Cisco UCS 5108 In-Reply-To: <4ED173A868981548967B4FCA2707222628021A09@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222628021A09@AACMBXP04.exchserver.com> Message-ID: <5460A4B5.9070701@redhat.com> On 11/10/2014 07:46 AM, Les Stott wrote: > Hi all, > > I have a FreeIPA environment with standard rhel6 package sets. > > Everything is working well. > > I would like to get our Cisco UCS 5108 authenticating via ldap with TLS using ldap group based checks. The ucs manager runs the latest 2.2(3a) > > Currently I have it authenticating via radius (which auth's to the ldap server in freeipa), but the radius setup doesn't allow for more fine grained group access controls. > > I've tried may things to get ldap to work, but failing miserably. According to the doc's it should be fairly straight forward (I wish it was!). > > Has anyone got a Cisco UCS device to be able to authenticate successfully using LDAP over TLS with FreeIPA? > > I'd appreciate any feedback so I know whether it is actually possible or not. > > Thanks, > > Les Hello Les, I think you will need to better describe what exactly is not working for you, what you mean by fine grained control and provide the related logs or errors of what is not working, if available. Otherwise it will be difficult to advise, for people not intimately familiar with Cisco UCS device. Martin From mkosek at redhat.com Mon Nov 10 11:49:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 12:49:46 +0100 Subject: [Freeipa-users] restored replica ssl issue In-Reply-To: <4ED173A868981548967B4FCA2707222628021BE5@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222628021BE5@AACMBXP04.exchserver.com> Message-ID: <5460A65A.4040205@redhat.com> On 11/10/2014 08:34 AM, Les Stott wrote: > Hi all, > > I have a standard freeipa environment under rhel6. > > One of my replica servers, lets call it "serverB" had issues and I eventually rebuilt it. > > I rebuilt and restored data, but something wasn't right. Replication wasn't working. I had tried to re-initialize replication but it didn't help. > > The last thing I did was to .... > > On serverB > ipa-server-install --uninstall > getcert list > # remove the cert from being tracked (as per info shown after completion of ipa-server-install --uninstall > getcert stop-tracking -i 20131216070540 > rm /var/lib/ipa/replica-info-serverB.mydomain.com.gpg > > On server (the master) > ipa host-del serverB.mydomain.com.gpg > ipa-replica-manage del serverB.mydomain.com.gpg --force You do not have to run host-del, "ipa-replica-manage del" should take care of all records, AFAIK. > cd /var/lib/ipa > rm replica-info- serverB.mydomain.com.gpg > > This all appeared fine, and seemingly removes serverB completely. So, I then set it back up as a replica in the normal way I am not sure I follow. What did you do exactly ("set it back up as a replica")? Did you simply reinstall replica with ipa-replica-install or did you do some other step? > ,and this worked well. Replication is working and all looks good except for the FreeIPA Web interface. > > When I try to browse to https://serverB.mydomain.com/ipa/ui/ I get "unknown Error" in a popup box. > > In the apache error log I see.... > [Mon Nov 10 02:08:37 2014] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate > > I am not sure what "Peer" references - serverB locally? Peer should be the machine where you run the browser. You can check the Server-Cert in /etc/httpd/alias/ database to see what changed. > My gut feel is that perhaps there were leftover remnants (possibly in ipa httpd config) from after the uninstall and the reinstall didn't overwrite them.. I did not reproduce it myself, but it can happen. We have a ticket filed for https://fedorahosted.org/freeipa/ticket/4639 Workaround would be to remove all contents of this directory before replica installation. But I would wait with advisory until I see what really happened. > Can anyone shed any light on the error above? > > Thanks in advance, > > Les > > > From mkosek at redhat.com Mon Nov 10 11:56:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 12:56:00 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> Message-ID: <5460A7D0.5060203@redhat.com> On 11/10/2014 02:05 AM, Rolf Nufable wrote: > Hello > > I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > > I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I assume this is a problem in SSSD client part, if the user cannot be found. CCing Lukas and Jakub to advise. From jhrozek at redhat.com Mon Nov 10 12:41:37 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Nov 2014 13:41:37 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5460A7D0.5060203@redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> Message-ID: <20141110124137.GF5577@hendrix.brq.redhat.com> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > On 11/10/2014 02:05 AM, Rolf Nufable wrote: > > Hello > > > > I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > > > > I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. > > I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I > assume this is a problem in SSSD client part, if the user cannot be found. > CCing Lukas and Jakub to advise. Sorry, I skipped this thread b/c the subject didn't look like it was SSSD-related. I think we need to examine SSSD logs... From dpal at redhat.com Mon Nov 10 13:38:13 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Nov 2014 08:38:13 -0500 Subject: [Freeipa-users] Apache WebDav file sharing permission problem In-Reply-To: References: Message-ID: <5460BFC5.90406@redhat.com> On 11/10/2014 12:14 AM, Thomas Lau wrote: > Hi All, > > I am successfully letting Apache auth against FreeIPA, but whatever > folder/files being created on WebDav server would be using Apache user > and group instead of login user/group, does anyone know how to fix this? > > Kerberos + LDAP config: > > http://pastebin.com/zpP3TEst > > -- > Thomas Lau > Director of Infrastructure > Tetrion Capital Limited > > Direct: +852-3976-8903 > Mobile: +852-9323-9670 > Address: 20/F, IFC 1, Central district, Hong Kong > > Can you please give a bit more context and architecture? Are you building you own WebDav server or using an existing implementation? Which one? Not being familiar with the internals of WebDav I would assume that impersonation would be a function of your WebDav server. However AFAIU it would need to use something like oddjob to create files and directories on the file system to make them be owned by the users. Also this might give you some hints on how we recommend to hook web applications into IPA. http://www.freeipa.org/page/Web_App_Authentication -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 10 13:44:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Nov 2014 08:44:41 -0500 Subject: [Freeipa-users] trouble with ldap authentication for a Cisco UCS 5108 In-Reply-To: <5460A4B5.9070701@redhat.com> References: <4ED173A868981548967B4FCA2707222628021A09@AACMBXP04.exchserver.com> <5460A4B5.9070701@redhat.com> Message-ID: <5460C149.50108@redhat.com> On 11/10/2014 06:42 AM, Martin Kosek wrote: > On 11/10/2014 07:46 AM, Les Stott wrote: >> Hi all, >> >> I have a FreeIPA environment with standard rhel6 package sets. >> >> Everything is working well. >> >> I would like to get our Cisco UCS 5108 authenticating via ldap with TLS using ldap group based checks. The ucs manager runs the latest 2.2(3a) >> >> Currently I have it authenticating via radius (which auth's to the ldap server in freeipa), but the radius setup doesn't allow for more fine grained group access controls. >> >> I've tried may things to get ldap to work, but failing miserably. According to the doc's it should be fairly straight forward (I wish it was!). >> >> Has anyone got a Cisco UCS device to be able to authenticate successfully using LDAP over TLS with FreeIPA? >> >> I'd appreciate any feedback so I know whether it is actually possible or not. >> >> Thanks, >> >> Les > Hello Les, > > I think you will need to better describe what exactly is not working for you, > what you mean by fine grained control and provide the related logs or errors of > what is not working, if available. > > Otherwise it will be difficult to advise, for people not intimately familiar > with Cisco UCS device. > > Martin > Les, Are you looking for something like this [1] for but for FreeIPA? What steps worked and what did not? [1] http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/sw/sample_configurations/UCSM_1_4_LDAP_with_AD/b_Sample_Configuration_LDAP_with_AD/b_Sample_Configuration_LDAP_with_AD_chapter_010.html#task_C46167F394AA4704A294E437C08BABC5 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Nov 10 13:48:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Nov 2014 08:48:15 -0500 Subject: [Freeipa-users] DNS and $GENERATE Directive In-Reply-To: <54607664.5070206@redhat.com> References: <545D52E1.3060005@atcri.com> <54607664.5070206@redhat.com> Message-ID: <5460C21F.9090207@redhat.com> On 11/10/2014 03:25 AM, Martin Kosek wrote: > On 11/08/2014 12:16 AM, Andrew Powell wrote: >> Is there a way to add a Bind $GENERATE directive line to FreeIPA to >> automatically name DHCP-assigned ranges? >> >> In a file-based Bind installation, I can have the following line in the forward >> example.com zone file: >> >> $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$ >> >> (which adds records wd080.example.com thru wd250.example.com) >> >> And for the reverse zone (0.168.192.in-addr.arpa) I can have the following line: >> >> $generate 80-250/1 $ PTR wd${0,3,d}.example.com. >> >> I can do without naming the DHCP-assigned ranges, but it seems like the proper >> thing to do. >> > Interesting question. I do not think bind-dyndb-ldap supports the $GENERATE > directive. I am not even sure how to extend LDAP DNS tree to support it as it > has a very specific syntax. You would need to add a new LDAP space accepting > strings that would be then passed to BIND... I will let Petr to assess if this > is possible or not. > > For now, the best approach would be to either add all these records to LDAP or > to have it in a BIND zone file and synchronize between all FreeIPA DNS servers. > > Martin > Would an ipa command solve the problem? Something like: ipa dns-generate 80-250/1 $ PTR wd${0,3,d}.example.com. If yes please file an RFE. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From natxo.asenjo at gmail.com Mon Nov 10 15:17:49 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 10 Nov 2014 16:17:49 +0100 Subject: [Freeipa-users] certmonger question Message-ID: hi, is this the right list to post certmonger questions? Here I see only a developer's list without too much activity: https://fedorahosted.org/certmonger/ My question is simple. After upgrading a vm running centos 6.5 to 6.6 I am seeing this error on reboot in messages: Nov 10 15:51:31 apachetest03 certmonger: Decoding error on "TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkFEQTdNUmt3#012RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZE#012WlhKMGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUx#012V2hjTk1qQXhNVEEzTWpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xT#012U1ZOYVQxSkhMazVNTVI0d0hBWURWUVFERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJv#012YjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC#012QVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1STlpdyt6#012QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51#012clVmZ2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpR#012TC9yRVVxV2t0bVpqYW5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcv#012engwZUFPWWdaVzV5eDNhQTVRNEZ1OHFXcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJh#012N2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRvazFHK1VWRXA0NUlOcGZ4#012cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSdzBvN1Ux#012eUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0#012eno3cU0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05W#012SFE4QkFmOEVCQU1DQWNZd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBX#012STk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VCQkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlv#012YUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjbWN1Ym13Nk9EQXZZMkV2#012YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE9NNVBU#012S0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1gr#012ankwOWM5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitE#012YnBlcC9Sc1FqSHJaK3Vud0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRI#012MUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY0hSc0dhZXJOU0NacC85MHlSSnlwQzNN#012T29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2NpdWp3d1lITnpzU3FZ#012Y0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHVqVnlC#012S2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==#012" (1240 bytes)! The certmonger service keeps stopping (nothing logged), I notice when running: $ sudo getcert list Please verify that the certmonger service has been started. This I got right after restarting it and getting a right result, with about 5 minutes in between. Now it's done i again: ]$ sudo getcert list Number of certificates and requests being tracked: 1. Request ID '20140410142412': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - apachetest03.domain.tld',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - apachetest03.domain.tld',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DOMAIN.TLD subject: CN=apachetest03.domain.tld,O=DOMAIN.TLD expires: 2016-04-10 14:24:15 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes ]$ sudo getcert list Please verify that the certmonger service has been started. How can I debug this? Thanks in advance. -- Groeten, natxo From rcritten at redhat.com Mon Nov 10 15:30:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Nov 2014 10:30:50 -0500 Subject: [Freeipa-users] Apache WebDav file sharing permission problem In-Reply-To: References: Message-ID: <5460DA2A.3040205@redhat.com> Thomas Lau wrote: > Hi All, > > I am successfully letting Apache auth against FreeIPA, but whatever > folder/files being created on WebDav server would be using Apache user > and group instead of login user/group, does anyone know how to fix this? > > Kerberos + LDAP config: > > http://pastebin.com/zpP3TEst It looks like this is just the way mod_dav works. From http://httpd.apache.org/docs/current/mod/mod_dav.html """ In order for mod_dav to manage files, it must be able to write to the directories and files under its control using the User and Group under which Apache is running. New files created will also be owned by this User and Group. """ rob From tlau at tetrioncapital.com Mon Nov 10 15:33:53 2014 From: tlau at tetrioncapital.com (tlau at tetrioncapital.com) Date: Mon, 10 Nov 2014 23:33:53 +0800 Subject: [Freeipa-users] Apache WebDav file sharing permission problem In-Reply-To: <5460DA2A.3040205@redhat.com> References: <5460DA2A.3040205@redhat.com> Message-ID: <20141110153353.5910674.10716.1016@tetrioncapital.com> Yeah, thanks for pointing it out, I am very upset now. Sent from my BlackBerry 10 smartphone. ? Original Message ? From: Rob Crittenden Sent: Monday, 10 November, 2014 11:30 PM To: Thomas Lau; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Apache WebDav file sharing permission problem Thomas Lau wrote: > Hi All, > > I am successfully letting Apache auth against FreeIPA, but whatever > folder/files being created on WebDav server would be using Apache user > and group instead of login user/group, does anyone know how to fix this? > > Kerberos + LDAP config: > > http://pastebin.com/zpP3TEst It looks like this is just the way mod_dav works. From http://httpd.apache.org/docs/current/mod/mod_dav.html """ In order for mod_dav to manage files, it must be able to write to the directories and files under its control using the User and Group under which Apache is running. New files created will also be owned by this User and Group. """ rob From simo at redhat.com Mon Nov 10 15:38:07 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 10 Nov 2014 10:38:07 -0500 Subject: [Freeipa-users] Apache WebDav file sharing permission problem In-Reply-To: References: Message-ID: <20141110103807.2bcb7984@willson.usersys.redhat.com> On Mon, 10 Nov 2014 13:14:38 +0800 Thomas Lau wrote: > Hi All, > > I am successfully letting Apache auth against FreeIPA, but whatever > folder/files being created on WebDav server would be using Apache > user and group instead of login user/group, does anyone know how to > fix this? > > Kerberos + LDAP config: > > http://pastebin.com/zpP3TEst Hi Thomas, I do not think mod_dav can use anything but pache's own user. If you find a CGI that implements dav though, then you could use SuEXEC to do what you want: http://httpd.apache.org/docs/2.4/suexec.html NOTE: this is a little off topic for the FreeIPA list, I think you'll find more expertise on some Apache related user mailing lists. Regards, Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Nov 10 15:49:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 16:49:01 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: References: Message-ID: <5460DE6D.8060007@redhat.com> On 11/10/2014 04:17 PM, Natxo Asenjo wrote: > hi, > > is this the right list to post certmonger questions? It is. Certmonger is part of IPA solution so this list is a good start. CCing Nalin as he is still the SME for certmonger, he may have some idea. > Here I see only a developer's list without too much activity: > https://fedorahosted.org/certmonger/ > > My question is simple. After upgrading a vm running centos 6.5 to 6.6 > I am seeing this error on reboot in messages: > > Nov 10 15:51:31 apachetest03 certmonger: Decoding error on > "TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkFEQTdNUmt3#012RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZE#012WlhKMGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUx#012V2hjTk1qQXhNVEEzTWpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xT#012U1ZOYVQxSkhMazVNTVI0d0hBWURWUVFERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJv#012YjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC#012QVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1STlpdyt6#012QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51#012clVmZ2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpR#012TC9yRVVxV2t0bVpqYW5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcv#012engwZUFPWWdaVzV5eDNhQTVRNEZ1OHFXcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJh#012N2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRvazFHK1VWRXA0NUlOcGZ4#012cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSdzBvN1Ux#012eUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0#012eno3cU0vSzhrOVlqM3FtRU5tZ3dEd1lEVl! Iw! > VEFRSC9CQVV3QXdFQi96QU9CZ05W#012SFE4QkFmOEVCQU1DQWNZd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBX#012STk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VCQkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlv#012YUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjbWN1Ym13Nk9EQXZZMkV2#012YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE9NNVBU#012S0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1gr#012ankwOWM5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitE#012YnBlcC9Sc1FqSHJaK3Vud0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRI#012MUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY0hSc0dhZXJOU0NacC85MHlSSnlwQzNN#012T29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2NpdWp3d1lITnpzU3FZ#012Y0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHVqVnlC#012S2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==#012" > (1240 bytes)! > > The certmonger service keeps stopping (nothing logged), I notice when running: > > $ sudo getcert list > Please verify that the certmonger service has been started. > > This I got right after restarting it and getting a right result, with > about 5 minutes in between. Now it's done i again: > > > ]$ sudo getcert list > Number of certificates and requests being tracked: 1. > Request ID '20140410142412': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate > - apachetest03.domain.tld',token='NSS Certificate DB' > certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA > Machine Certificate - apachetest03.domain.tld',token='NSS Certificate > DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOMAIN.TLD > subject: CN=apachetest03.domain.tld,O=DOMAIN.TLD > expires: 2016-04-10 14:24:15 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > ]$ sudo getcert list > Please verify that the certmonger service has been started. > > How can I debug this? > > Thanks in advance. > -- > Groeten, > natxo > From mkosek at redhat.com Mon Nov 10 15:50:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 16:50:25 +0100 Subject: [Freeipa-users] DNS and $GENERATE Directive In-Reply-To: <5460C21F.9090207@redhat.com> References: <545D52E1.3060005@atcri.com> <54607664.5070206@redhat.com> <5460C21F.9090207@redhat.com> Message-ID: <5460DEC1.4080002@redhat.com> On 11/10/2014 02:48 PM, Dmitri Pal wrote: > On 11/10/2014 03:25 AM, Martin Kosek wrote: >> On 11/08/2014 12:16 AM, Andrew Powell wrote: >>> Is there a way to add a Bind $GENERATE directive line to FreeIPA to >>> automatically name DHCP-assigned ranges? >>> >>> In a file-based Bind installation, I can have the following line in the forward >>> example.com zone file: >>> >>> $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$ >>> >>> (which adds records wd080.example.com thru wd250.example.com) >>> >>> And for the reverse zone (0.168.192.in-addr.arpa) I can have the following >>> line: >>> >>> $generate 80-250/1 $ PTR wd${0,3,d}.example.com. >>> >>> I can do without naming the DHCP-assigned ranges, but it seems like the proper >>> thing to do. >>> >> Interesting question. I do not think bind-dyndb-ldap supports the $GENERATE >> directive. I am not even sure how to extend LDAP DNS tree to support it as it >> has a very specific syntax. You would need to add a new LDAP space accepting >> strings that would be then passed to BIND... I will let Petr to assess if this >> is possible or not. >> >> For now, the best approach would be to either add all these records to LDAP or >> to have it in a BIND zone file and synchronize between all FreeIPA DNS servers. >> >> Martin >> > Would an ipa command solve the problem? > Something like: > > ipa dns-generate 80-250/1 $ PTR wd${0,3,d}.example.com. > > If yes please file an RFE. Potentially yes, I just wanted to first have some assessment from Petr to see if it even makes sense from bind-dyndb-ldap POV. Maybe bind-dyndb-ldap cannot hook into the BIND zone file macro generation so the RFE would not even make sense. Martin From nalin at redhat.com Mon Nov 10 16:19:34 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 10 Nov 2014 11:19:34 -0500 Subject: [Freeipa-users] certmonger question In-Reply-To: References: Message-ID: <20141110161934.GA13814@redhat.com> On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote: > Nov 10 15:51:31 apachetest03 certmonger: Decoding error on > "TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkFEQTdNUmt3#012RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZE#012WlhKMGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUx#012V2hjTk1qQXhNVEEzTWpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xT#012U1ZOYVQxSkhMazVNTVI0d0hBWURWUVFERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJv#012YjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC#012QVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1STlpdyt6#012QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51#012clVmZ2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpR#012TC9yRVVxV2t0bVpqYW5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcv#012engwZUFPWWdaVzV5eDNhQTVRNEZ1OHFXcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJh#012N2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRvazFHK1VWRXA0NUlOcGZ4#012cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSdzBvN1Ux#012eUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0#012eno3cU0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIw! > VEFRSC9CQVV3QXdFQi96QU9CZ05W#012SFE4QkFmOEVCQU1DQWNZd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBX#012STk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VCQkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlv#012YUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjbWN1Ym13Nk9EQXZZMkV2#012YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE9NNVBU#012S0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1gr#012ankwOWM5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitE#012YnBlcC9Sc1FqSHJaK3Vud0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRI#012MUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY0hSc0dhZXJOU0NacC85MHlSSnlwQzNN#012T29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2NpdWp3d1lITnpzU3FZ#012Y0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHVqVnlC#012S2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==#012" > (1240 bytes)! > > The certmonger service keeps stopping (nothing logged), I notice when running: > > $ sudo getcert list > Please verify that the certmonger service has been started. > > This I got right after restarting it and getting a right result, with > about 5 minutes in between. Now it's done i again: > > ]$ sudo getcert list > Number of certificates and requests being tracked: 1. > Request ID '20140410142412': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate > - apachetest03.domain.tld',token='NSS Certificate DB' > certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA > Machine Certificate - apachetest03.domain.tld',token='NSS Certificate > DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOMAIN.TLD > subject: CN=apachetest03.domain.tld,O=DOMAIN.TLD > expires: 2016-04-10 14:24:15 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > ]$ sudo getcert list > Please verify that the certmonger service has been started. > > How can I debug this? First thing would be to run the daemon with additional logging - I usually use '-d3' to watch what's going on while the daemon's running various tasks. The data logged with the Decoding Error looks like a certificate that's been base64-encoded, and then base64-encoded again, which is very odd, since that error message is logged in cases where it fails to parse a root certificate that it has just retrieved from the CA, and that data shouldn't have been mangled like that. Can you check the contents of the "caCertificate" attribute in the "cn=cacert,cn=ipa,cn=etc" entry under the IPA base DN in the directory server, and perhaps provide them? They can be retrieved using a command like: ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI caCertificate The attribute values are supposed to be certificates in binary form, which ldapsearch will likely base64-encode for display -- ldapsearch will indicate that it's doing this by separating the attribute name from the value using two colons ('::') instead of the usual one (':') in its output, in accordance with ldif(5). HTH, Nalin From mlasevich at gmail.com Mon Nov 10 17:29:04 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 10 Nov 2014 09:29:04 -0800 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <20141110101045.GD5577@hendrix.brq.redhat.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4BE7FD@SC-EXCHANGE.speedcast.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> <20141110101045.GD5577@hendrix.brq.redhat.com> Message-ID: I can certainly try, it would need to be compatible with CentOS 6.6 though. -M > So according to the logs, the create_ccache() function failed. Unfortunately, we don't do very good job at logging the failures there.. > >Michael, are you able to run a custom package with extra debugging? It would help us pinpoint which line actually is failing. > >Thanks a lot for providing the logs! -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Mon Nov 10 17:58:15 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 10 Nov 2014 09:58:15 -0800 Subject: [Freeipa-users] strange error deleting replica? Message-ID: <5460FCB7.3060309@gmail.com> Hi -- Has anyone seen this before? # ipa-replica-manage del kermit.xyzzy.com --force unexpected error: [Errno -2] Name or service not known ?? Very confused as to What service or name is not known? This is 4.0.5 running on CentOS 7. ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Nov 10 21:43:39 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 10 Nov 2014 21:43:39 +0000 Subject: [Freeipa-users] getting rid of private groups Message-ID: Trying to learn to live without private groups. I imported a bunch of users from OpenLDAP and that was good. I created about 4 users and the private groups show up in odd places and I don't want them. The private groups offer little value since the bulk of the imported users don't have them anyway. I have done... ipa-managed-entries -e "UPG Definition" disable ipa-managed-entries -e "NGP Definition" disable ldapmodify -Y GSSAPI dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX changetype: modify replace: originfilter originfilter: (objectclass=disabled) and restarted dirsrv but they are still showing - and I can't delete them ;-( ipa group-del test ipa: ERROR: Deleting a managed group is not allowed. It must be detached first. In the 'stash' application, I am trying to obscure them with an LDAP filter but that isn't working either (&(objectclass=posixGroup)(!(objectclass=mepManagedEntry))) How can I get rid of the these private groups? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From william.muriithi at gmail.com Mon Nov 10 22:04:02 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 10 Nov 2014 17:04:02 -0500 Subject: [Freeipa-users] Possible trust issues Message-ID: <20141110220402.6008977.15908.7965@gmail.com> ?Evening, ?I have been trying to get IPA server working using AD users and I think I need some assistance as I have run into the wall. ?Below is some background information. ?The active directory domain is called example.local and the IPA domain is called example.loc. ?My plan is to map domain users on AD to ad_users on IPA servers. ?I am using CentOS Linux release 7.0.1406 (Core) with below RPM [root at ipa3-yyz-int ~]# rpm -qa | grep ipa ipa-client-3.3.3-28.el7.centos.1.x86_64 iniparser-3.1-5.el7.x86_64 ipa-server-trust-ad-3.3.3-28.el7.centos.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 ipa-python-3.3.3-28.el7.centos.1.x86_64 ipa-server-3.3.3-28.el7.centos.1.x86_64 libipa_hbac-1.11.2-68.el7_0.5.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7.centos.1.x86_64 I have two groups? [root at ipa3-yyz-int ~]# ipa group-show --all ad_users ? dn: cn=ad_users,cn=groups,cn=accounts,dc=example,dc=loc ? Group name: ad_users ? Description: ad_domain users ? GID: 1963800005 ? Member users: williamm_user, wmuriithi_user ? Member of HBAC rule: dev-systems-rules ? ipantsecurityidentifier: S-1-5-21-3033893191-3803153583-4018222701-1005 ? ipauniqueid: eec320c2-650b-11e4-bc2c-000c29c42447 ? objectclass: top, groupofnames, nestedgroup, ipausergroup, ipaobject, posixgroup, ipantgroupattrs [root at ipa3-yyz-int ~]# ipa group-show --all ad_users_external ? dn: cn=ad_users_external,cn=groups,cn=accounts,dc=example,dc=loc ? Group name: ad_users_external ? Description: ad_domain users external map ? External member: S-1-5-21-205922407-570005376-4065188459-513 ? ipauniqueid: d3b2759e-650b-11e4-8518-000c29c42447 ? objectclass: top, groupofnames, nestedgroup, ipausergroup, ipaobject, ipaexternalgroup I am certain the problem has something to do with trust as I have created a local account on FreeIPA (wmuriithi_user) and it works as expected. ?However active directory users in the same posix group fails and have not been able to nail where my mistake. ?How would one go about debugging this issue? ?I have looked at logs and the looks as below. cat /var/log/secure Nov 10 12:12:05 datagroup-dev sshd[30150]: Invalid user wmuriithi at example.local from 10.10.10.15 Nov 10 12:12:05 datagroup-dev sshd[30151]: input_userauth_request: invalid user wmuriithi at example.local Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): check pass; user unknown Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.10.15 Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_succeed_if(sshd:auth): error retrieving information about user wmuriithi at example.local Nov 10 12:12:11 datagroup-dev sshd[30150]: Failed password for invalid user wmuriithi at example.local from 10.10.10.15 port 52792 ssh2 Nov 10 12:12:17 datagroup-dev sshd[30151]: Connection closed by 10.10.10.15 cat /var/log/sssd/sssd_ssh.log (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_next] (0x0040): No attributes for user [wmuriithi] found. (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed less /var/log/sssd/sssd_example.loc.log (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working' (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [set_server_common_status] (0x0100): Marking server 'ipa3-yyz-int.example.loc' as 'working' (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. Does this mean I have to recreate the trust relationship? ?I didn't get any error when I set up the trust last week and uncertain recreating the trust would help. ?Would highly appreciate any pointers on what would be best way forward. William? From rcritten at redhat.com Mon Nov 10 22:13:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Nov 2014 17:13:48 -0500 Subject: [Freeipa-users] getting rid of private groups In-Reply-To: References: Message-ID: <5461389C.9030709@redhat.com> Craig White wrote: > Trying to learn to live without private groups. > > > > I imported a bunch of users from OpenLDAP and that was good. > > > > I created about 4 users and the private groups show up in odd places and > I don?t want them. The private groups offer little value since the bulk > of the imported users don?t have them anyway. > > > > I have done > > > > ipa-managed-entries -e "UPG Definition" disable > > ipa-managed-entries -e "NGP Definition" disable > > > > ldapmodify -Y GSSAPI > > dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX > > changetype: modify > > replace: originfilter > > originfilter: (objectclass=disabled) > > > > and restarted dirsrv but they are still showing ? and I can?t delete > them ;-( > > > > ipa group-del test > > ipa: ERROR: Deleting a managed group is not allowed. It must be detached > first. > > > > In the ?stash? application, I am trying to obscure them with an LDAP > filter but that isn?t working either > > (&(objectclass=posixGroup)(!(objectclass=mepManagedEntry))) > > > > How can I get rid of the these private groups? $ ipa group-detach test $ ipa group-del test rob From CWhite at skytouchtechnology.com Mon Nov 10 22:16:48 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 10 Nov 2014 22:16:48 +0000 Subject: [Freeipa-users] getting rid of private groups In-Reply-To: <5461389C.9030709@redhat.com> References: <5461389C.9030709@redhat.com> Message-ID: -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, November 10, 2014 3:14 PM To: Craig White; freeipa-users at redhat.com Subject: Re: [Freeipa-users] getting rid of private groups Craig White wrote: > Trying to learn to live without private groups. > > > > I imported a bunch of users from OpenLDAP and that was good. > > > > I created about 4 users and the private groups show up in odd places > and I don't want them. The private groups offer little value since the > bulk of the imported users don't have them anyway. > > > > I have done... > > > > ipa-managed-entries -e "UPG Definition" disable > > ipa-managed-entries -e "NGP Definition" disable > > > > ldapmodify -Y GSSAPI > > dn: cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX > > changetype: modify > > replace: originfilter > > originfilter: (objectclass=disabled) > > > > and restarted dirsrv but they are still showing - and I can't delete > them ;-( > > > > ipa group-del test > > ipa: ERROR: Deleting a managed group is not allowed. It must be > detached first. > > > > In the 'stash' application, I am trying to obscure them with an LDAP > filter but that isn't working either > > (&(objectclass=posixGroup)(!(objectclass=mepManagedEntry))) > > > > How can I get rid of the these private groups? $ ipa group-detach test $ ipa group-del test ---- A BGO ! (blinding glimpse of the obvious) ;-) As you can tell, I did research it. Thanks Rob From william.muriithi at gmail.com Tue Nov 11 00:01:18 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 10 Nov 2014 19:01:18 -0500 Subject: [Freeipa-users] Possible trust issues In-Reply-To: <20141110220402.6008977.15908.7965@gmail.com> References: <20141110220402.6008977.15908.7965@gmail.com> Message-ID: <20141111000118.6008977.95066.7974@gmail.com> ?Evening, Also, this show up on /var/log/krb5kdc.log on ipa server Nov 10 18:43:22 ipa3-yyz-int.example.loc krb5kdc[5469](info): AS_REQ (4 etypes {18 17 16 23}) 10.10.10.29: NEEDED_PREAUTH: host/sogo-eval.example.loc at EXAMPLE.LOC for krbtgt/EXAMPLE.LOC at EXAMPLE.LOC, Additional pre-authentication required Nov 10 18:43:22 ipa3-yyz-int.example.loc krb5kdc[5468](info): AS_REQ (4 etypes {18 17 16 23}) 10.10.10.29: ISSUE: authtime 1415663002, etypes {rep=18 tkt=18 ses=18}, host/sogo-eval.example.loc at EXAMPLE.LOC for krbtgt/EXAMPLE.LOC at EXAMPLE.LOC What does pre-authentication required mean? William? I am certain the problem has something to do with trust as I have created a local account on FreeIPA (wmuriithi_user) and it works as expected. ?However active directory users in the same posix group fails and have not been able to nail where my mistake. ?How would one go about debugging this issue? ?I have looked at logs and the looks as below. cat /var/log/secure Nov 10 12:12:05 datagroup-dev sshd[30150]: Invalid user wmuriithi at example.local from 10.10.10.15 Nov 10 12:12:05 datagroup-dev sshd[30151]: input_userauth_request: invalid user wmuriithi at example.local Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): check pass; user unknown Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.10.15 Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_succeed_if(sshd:auth): error retrieving information about user wmuriithi at example.local Nov 10 12:12:11 datagroup-dev sshd[30150]: Failed password for invalid user wmuriithi at example.local from 10.10.10.15 port 52792 ssh2 Nov 10 12:12:17 datagroup-dev sshd[30151]: Connection closed by 10.10.10.15 cat /var/log/sssd/sssd_ssh.log (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_next] (0x0040): No attributes for user [wmuriithi] found. (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed less /var/log/sssd/sssd_example.loc.log (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working' (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [set_server_common_status] (0x0100): Marking server 'ipa3-yyz-int.example.loc' as 'working' (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. Does this mean I have to recreate the trust relationship? ?I didn't get any error when I set up the trust last week and uncertain recreating the trust would help. ?Would highly appreciate any pointers on what would be best way forward. William? From dpal at redhat.com Tue Nov 11 00:05:55 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Nov 2014 19:05:55 -0500 Subject: [Freeipa-users] Possible trust issues In-Reply-To: <20141111000118.6008977.95066.7974@gmail.com> References: <20141110220402.6008977.15908.7965@gmail.com> <20141111000118.6008977.95066.7974@gmail.com> Message-ID: <546152E3.6070902@redhat.com> On 11/10/2014 07:01 PM, William Muriithi wrote: > ?Evening, > > Also, this show up on /var/log/krb5kdc.log on ipa server > > Nov 10 18:43:22 ipa3-yyz-int.example.loc krb5kdc[5469](info): AS_REQ (4 etypes {18 17 16 23}) 10.10.10.29: NEEDED_PREAUTH: host/sogo-eval.example.loc at EXAMPLE.LOC for krbtgt/EXAMPLE.LOC at EXAMPLE.LOC, Additional pre-authentication required > Nov 10 18:43:22 ipa3-yyz-int.example.loc krb5kdc[5468](info): AS_REQ (4 etypes {18 17 16 23}) 10.10.10.29: ISSUE: authtime 1415663002, etypes {rep=18 tkt=18 ses=18}, host/sogo-eval.example.loc at EXAMPLE.LOC for krbtgt/EXAMPLE.LOC at EXAMPLE.LOC > > What does pre-authentication required mean? It is normal. http://superuser.com/questions/200010/how-does-kerberos-preauthentication-increase-security > > William? > > > > I am certain the problem has something to do with trust as I have created a local account on FreeIPA (wmuriithi_user) and it works as expected. However active directory users in the same posix group fails and have not been able to nail where my mistake. How would one go about debugging this issue? I have looked at logs and the looks as below. > > cat /var/log/secure > > Nov 10 12:12:05 datagroup-dev sshd[30150]: Invalid user wmuriithi at example.local from 10.10.10.15 > Nov 10 12:12:05 datagroup-dev sshd[30151]: input_userauth_request: invalid user wmuriithi at example.local > Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): check pass; user unknown > Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.10.15 > Nov 10 12:12:09 datagroup-dev sshd[30150]: pam_succeed_if(sshd:auth): error retrieving information about user wmuriithi at example.local > Nov 10 12:12:11 datagroup-dev sshd[30150]: Failed password for invalid user wmuriithi at example.local from 10.10.10.15 port 52792 ssh2 > Nov 10 12:12:17 datagroup-dev sshd[30151]: Connection closed by 10.10.10.15 > > cat /var/log/sssd/sssd_ssh.log > > > (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi > (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 1432158221, Account info lookup failed > (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [ssh_user_pubkeys_search_next] (0x0040): No attributes for user [wmuriithi] found. > (Mon Nov 10 12:34:01 2014) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! > (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. > (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. > (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'wmuriithi at example.local' matched expression for domain 'EXAMPLE.local', user is wmuriithi > (Mon Nov 10 15:16:44 2014) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 1432158221, Account info lookup failed > > > less /var/log/sssd/sssd_example.loc.log > > (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working' > (Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [set_server_common_status] (0x0100): Marking server 'ipa3-yyz-int.example.loc' as 'working' > (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > (Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > > Does this mean I have to recreate the trust relationship? I didn't get any error when I set up the trust last week and uncertain recreating the trust would help. Would highly appreciate any pointers on what would be best way forward. > > William? > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Less at imagine-sw.com Tue Nov 11 00:15:50 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 11 Nov 2014 00:15:50 +0000 Subject: [Freeipa-users] restored replica ssl issue In-Reply-To: <5460A65A.4040205@redhat.com> References: <4ED173A868981548967B4FCA2707222628021BE5@AACMBXP04.exchserver.com> <5460A65A.4040205@redhat.com> Message-ID: <4ED173A868981548967B4FCA270722262802330D@AACMBXP04.exchserver.com> > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: Monday, 10 November 2014 10:50 PM > To: Les Stott; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] restored replica ssl issue > > On 11/10/2014 08:34 AM, Les Stott wrote: > > Hi all, > > > > I have a standard freeipa environment under rhel6. > > > > One of my replica servers, lets call it "serverB" had issues and I eventually > rebuilt it. > > > > I rebuilt and restored data, but something wasn't right. Replication wasn't > working. I had tried to re-initialize replication but it didn't help. > > > > The last thing I did was to .... > > > > On serverB > > ipa-server-install --uninstall > > getcert list > > # remove the cert from being tracked (as per info shown after > > completion of ipa-server-install --uninstall getcert stop-tracking -i > > 20131216070540 rm /var/lib/ipa/replica-info-serverB.mydomain.com.gpg > > > > On server (the master) > > ipa host-del serverB.mydomain.com.gpg > > ipa-replica-manage del serverB.mydomain.com.gpg --force > > You do not have to run host-del, "ipa-replica-manage del" should take care of > all records, AFAIK. > > > cd /var/lib/ipa > > rm replica-info- serverB.mydomain.com.gpg > > > > This all appeared fine, and seemingly removes serverB completely. So, > > I then set it back up as a replica in the normal way > > I am not sure I follow. What did you do exactly ("set it back up as a replica")? > Did you simply reinstall replica with ipa-replica-install or did you do some > other step? Yes, this is what I did. > > > ,and this worked well. Replication is working and all looks good except for > the FreeIPA Web interface. > > > > When I try to browse to https://serverB.mydomain.com/ipa/ui/ I get > "unknown Error" in a popup box. > > > > In the apache error log I see.... > > [Mon Nov 10 02:08:37 2014] [error] SSL Library Error: -12195 Peer does > > not recognize and trust the CA that issued your certificate > > > > I am not sure what "Peer" references - serverB locally? > > Peer should be the machine where you run the browser. You can check the > Server-Cert in /etc/httpd/alias/ database to see what changed. > Thanks for clarifying that about the peer. Turns out that it was just a saved cert in the browser. Once I removed the saved cert in my browser I could connect and add the new certificate into the browser. Nothing server-side was wrong. Thanks Martin. Regards, Les From Less at imagine-sw.com Tue Nov 11 01:40:50 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 11 Nov 2014 01:40:50 +0000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? Message-ID: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> Hi, I have a standard rhel6 deployment for FreeIPA in two environments. One environment is in our Production Data Center, The Other in our DR Data Center. Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of "0A" My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial)" If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the "same serial number" error pops up for browsing serverA. Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). Is there a way to generate unique serial numbers for the masters? Thanks in advance, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Nov 11 01:50:59 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Nov 2014 11:50:59 +1000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> Message-ID: <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > Hi, > > I have a standard rhel6 deployment for FreeIPA in two environments. > > One environment is in our Production Data Center, The Other in our DR Data Center. > > Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. > > In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. > > The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of "0A" > > My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). > > If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. > If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: > > "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial)" > > If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the "same serial number" error pops up for browsing serverA. > > Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). > > Is there a way to generate unique serial numbers for the masters? > > Thanks in advance, > > Les > > > Hi Les, Ideally, you should prevent this situation by using different common names (CN) for your CAs and server certifications across the different environments. If this is not possible, you can configure the Dogtag CA to use random serial numbers: http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_Use_Random_Certificate_Serial_Numbers This does not guarantee that you will not get serial number collisions, but reduces the likelihood. Regards, Fraser > -- > 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 From Less at imagine-sw.com Tue Nov 11 02:11:55 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 11 Nov 2014 02:11:55 +0000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> > -----Original Message----- > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > Sent: Tuesday, 11 November 2014 12:51 PM > To: Les Stott > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] how to overcome same serial number in cert > issue on different master servers? > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > Hi, > > > > I have a standard rhel6 deployment for FreeIPA in two environments. > > > > One environment is in our Production Data Center, The Other in our DR > Data Center. > > > > Both environments are setup with the same domain (mydomain.com) for > FreeIPA. This is to support dr/failover etc. > > > > In each environment, there is a master. In Prod its serverA.mydomain.com, > In DR its serverB.mydomain.com. > > > > The master in each environment gets a generated certificate by IPA. This > certificate shows a Serial Number of "0A" > > > > My problem is that because the certificates have the same Organization, > OU and Serial Number, I can only browse to one of them (using Firefox). > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the > certificate it works fine. > > If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes > up with the following error: > > > > "Your certificate contains the same serial number as another certificate > issued by the certificate authority. Please get a new certificate containing a > unique serial number. (Error code: sec_error_reused_issuer_and_serial)" > > > > If I remove the stored browser certificate for serverA, then browse to > serverB, and accept the certificate, it works, but then the "same serial > number" error pops up for browsing serverA. > > > > Note: both environments were built separately and are not linked in > anyway (no replication between prod/dr). > > > > Is there a way to generate unique serial numbers for the masters? > > > > Thanks in advance, > > > > Les > > > > > > > Hi Les, > > Ideally, you should prevent this situation by using different common names > (CN) for your CAs and server certifications across the different > environments. If this is not possible, you can configure the Dogtag CA to use > random serial numbers: > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > se_Random_Certificate_Serial_Numbers > > This does not guarantee that you will not get serial number collisions, but > reduces the likelihood. > Thanks for the quick reply. In this case the common name is different between both environments. In prod the master was serverA, in DR the master was serverB. It just happened that way. So having a different CommonName doesn't help. I'll look into the dogtag random certificate serial number generation. Does anyone know of a correct way to re-issue the cert's for each master with a random serial number? Thanks, Les From ftweedal at redhat.com Tue Nov 11 02:59:15 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Nov 2014 12:59:15 +1000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> Message-ID: <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > > -----Original Message----- > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > Sent: Tuesday, 11 November 2014 12:51 PM > > To: Les Stott > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] how to overcome same serial number in cert > > issue on different master servers? > > > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > > Hi, > > > > > > I have a standard rhel6 deployment for FreeIPA in two environments. > > > > > > One environment is in our Production Data Center, The Other in our DR > > Data Center. > > > > > > Both environments are setup with the same domain (mydomain.com) for > > FreeIPA. This is to support dr/failover etc. > > > > > > In each environment, there is a master. In Prod its serverA.mydomain.com, > > In DR its serverB.mydomain.com. > > > > > > The master in each environment gets a generated certificate by IPA. This > > certificate shows a Serial Number of "0A" > > > > > > My problem is that because the certificates have the same Organization, > > OU and Serial Number, I can only browse to one of them (using Firefox). > > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the > > certificate it works fine. > > > If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes > > up with the following error: > > > > > > "Your certificate contains the same serial number as another certificate > > issued by the certificate authority. Please get a new certificate containing a > > unique serial number. (Error code: sec_error_reused_issuer_and_serial)" > > > > > > If I remove the stored browser certificate for serverA, then browse to > > serverB, and accept the certificate, it works, but then the "same serial > > number" error pops up for browsing serverA. > > > > > > Note: both environments were built separately and are not linked in > > anyway (no replication between prod/dr). > > > > > > Is there a way to generate unique serial numbers for the masters? > > > > > > Thanks in advance, > > > > > > Les > > > > > > > > > > > Hi Les, > > > > Ideally, you should prevent this situation by using different common names > > (CN) for your CAs and server certifications across the different > > environments. If this is not possible, you can configure the Dogtag CA to use > > random serial numbers: > > > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > > se_Random_Certificate_Serial_Numbers > > > > This does not guarantee that you will not get serial number collisions, but > > reduces the likelihood. > > > > Thanks for the quick reply. > > In this case the common name is different between both > environments. In prod the master was serverA, in DR the master was > serverB. It just happened that way. So having a different > CommonName doesn't help. > Do the CA certificates bear the same commonName? This is probably what Firefox uses to determine if there are serial number collisions. > I'll look into the dogtag random certificate serial number > generation. > > Does anyone know of a correct way to re-issue the cert's for each > master with a random serial number? > > Thanks, > > Les > > > > > -- > 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 From Less at imagine-sw.com Tue Nov 11 04:17:37 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 11 Nov 2014 04:17:37 +0000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> Message-ID: <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> > -----Original Message----- > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > Sent: Tuesday, 11 November 2014 1:59 PM > To: Les Stott > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] how to overcome same serial number in cert > issue on different master servers? > > On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > > > -----Original Message----- > > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > > Sent: Tuesday, 11 November 2014 12:51 PM > > > To: Les Stott > > > Cc: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] how to overcome same serial number in > > > cert issue on different master servers? > > > > > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > > > Hi, > > > > > > > > I have a standard rhel6 deployment for FreeIPA in two environments. > > > > > > > > One environment is in our Production Data Center, The Other in our > > > > DR > > > Data Center. > > > > > > > > Both environments are setup with the same domain (mydomain.com) > > > > for > > > FreeIPA. This is to support dr/failover etc. > > > > > > > > In each environment, there is a master. In Prod its > > > > serverA.mydomain.com, > > > In DR its serverB.mydomain.com. > > > > > > > > The master in each environment gets a generated certificate by > > > > IPA. This > > > certificate shows a Serial Number of "0A" > > > > > > > > My problem is that because the certificates have the same > > > > Organization, > > > OU and Serial Number, I can only browse to one of them (using Firefox). > > > > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the > > > certificate it works fine. > > > > If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it > > > > comes > > > up with the following error: > > > > > > > > "Your certificate contains the same serial number as another > > > > certificate > > > issued by the certificate authority. Please get a new certificate > > > containing a unique serial number. (Error code: > sec_error_reused_issuer_and_serial)" > > > > > > > > If I remove the stored browser certificate for serverA, then > > > > browse to > > > serverB, and accept the certificate, it works, but then the "same > > > serial number" error pops up for browsing serverA. > > > > > > > > Note: both environments were built separately and are not linked > > > > in > > > anyway (no replication between prod/dr). > > > > > > > > Is there a way to generate unique serial numbers for the masters? > > > > > > > > Thanks in advance, > > > > > > > > Les > > > > > > > > > > > > > > > Hi Les, > > > > > > Ideally, you should prevent this situation by using different common > > > names > > > (CN) for your CAs and server certifications across the different > > > environments. If this is not possible, you can configure the Dogtag > > > CA to use random serial numbers: > > > > > > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > > > se_Random_Certificate_Serial_Numbers > > > > > > This does not guarantee that you will not get serial number > > > collisions, but reduces the likelihood. > > > > > > > Thanks for the quick reply. > > > > In this case the common name is different between both environments. > > In prod the master was serverA, in DR the master was serverB. It just > > happened that way. So having a different CommonName doesn't help. > > > Do the CA certificates bear the same commonName? This is probably what > Firefox uses to determine if there are serial number collisions. > It appears so. The certificate for the CA on the master serverA shows: Issued To Common Name (CN) serverA.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) The certificate for the CA on the master serverB shows: Issued To Common Name (CN) serverB.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) Shouldn't the Common Name of the CA be different? Or is it the same in order to make CA replication easier? Is there a way to re-issue certificates for the masters so they get unique serial numbers (without making the systems blow up)? Thanks, Les From ftweedal at redhat.com Tue Nov 11 05:16:07 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Nov 2014 15:16:07 +1000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> Message-ID: <20141111051607.GK3743@dhcp-40-8.bne.redhat.com> On Tue, Nov 11, 2014 at 04:17:37AM +0000, Les Stott wrote: > > -----Original Message----- > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > Sent: Tuesday, 11 November 2014 1:59 PM > > To: Les Stott > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] how to overcome same serial number in cert > > issue on different master servers? > > > > On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > > > > -----Original Message----- > > > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > > > Sent: Tuesday, 11 November 2014 12:51 PM > > > > To: Les Stott > > > > Cc: freeipa-users at redhat.com > > > > Subject: Re: [Freeipa-users] how to overcome same serial number in > > > > cert issue on different master servers? > > > > > > > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > > > > Hi, > > > > > > > > > > I have a standard rhel6 deployment for FreeIPA in two environments. > > > > > > > > > > One environment is in our Production Data Center, The Other in our > > > > > DR > > > > Data Center. > > > > > > > > > > Both environments are setup with the same domain (mydomain.com) > > > > > for > > > > FreeIPA. This is to support dr/failover etc. > > > > > > > > > > In each environment, there is a master. In Prod its > > > > > serverA.mydomain.com, > > > > In DR its serverB.mydomain.com. > > > > > > > > > > The master in each environment gets a generated certificate by > > > > > IPA. This > > > > certificate shows a Serial Number of "0A" > > > > > > > > > > My problem is that because the certificates have the same > > > > > Organization, > > > > OU and Serial Number, I can only browse to one of them (using Firefox). > > > > > > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the > > > > certificate it works fine. > > > > > If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it > > > > > comes > > > > up with the following error: > > > > > > > > > > "Your certificate contains the same serial number as another > > > > > certificate > > > > issued by the certificate authority. Please get a new certificate > > > > containing a unique serial number. (Error code: > > sec_error_reused_issuer_and_serial)" > > > > > > > > > > If I remove the stored browser certificate for serverA, then > > > > > browse to > > > > serverB, and accept the certificate, it works, but then the "same > > > > serial number" error pops up for browsing serverA. > > > > > > > > > > Note: both environments were built separately and are not linked > > > > > in > > > > anyway (no replication between prod/dr). > > > > > > > > > > Is there a way to generate unique serial numbers for the masters? > > > > > > > > > > Thanks in advance, > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > Hi Les, > > > > > > > > Ideally, you should prevent this situation by using different common > > > > names > > > > (CN) for your CAs and server certifications across the different > > > > environments. If this is not possible, you can configure the Dogtag > > > > CA to use random serial numbers: > > > > > > > > > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > > > > se_Random_Certificate_Serial_Numbers > > > > > > > > This does not guarantee that you will not get serial number > > > > collisions, but reduces the likelihood. > > > > > > > > > > Thanks for the quick reply. > > > > > > In this case the common name is different between both environments. > > > In prod the master was serverA, in DR the master was serverB. It just > > > happened that way. So having a different CommonName doesn't help. > > > > > Do the CA certificates bear the same commonName? This is probably what > > Firefox uses to determine if there are serial number collisions. > > > > It appears so. > > The certificate for the CA on the master serverA shows: > > Issued To > Common Name (CN) serverA.mydomain.com > Organization (O) mydomain.com > Organizational Unit (OU) > Serial Number 0A > Issued By: > Common Name (CN) Certificate Authority > Organization (O) mydomain.com > Organizational Unit (OU) > > The certificate for the CA on the master serverB shows: > > Issued To > Common Name (CN) serverB.mydomain.com > Organization (O) mydomain.com > Organizational Unit (OU) > Serial Number 0A > Issued By: > Common Name (CN) Certificate Authority > Organization (O) mydomain.com > Organizational Unit (OU) > > > Shouldn't the Common Name of the CA be different? Or is it the same in order to make CA replication easier? > Both environments were probably set up with the same CN for the CA (perhaps a default name). I don't think this has anything to do with replication. > Is there a way to re-issue certificates for the masters so they get unique serial numbers (without making the systems blow up)? > You can manually renew a certificate using Certmonger: http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate You should enable random serial numbers before doing this. > Thanks, > > Les > > > > -- > 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 From rolf_16_nufable at yahoo.com Tue Nov 11 05:24:22 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Mon, 10 Nov 2014 21:24:22 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <20141110124137.GF5577@hendrix.brq.redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> Message-ID: <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> well I'll try them now, my sssd config only consists of these lines added to the sudo area sudo_provider = ldap ldap_uri = ldap://myipaserver.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/myipaserver.example.com ldap_sasl_realm = EXAMPLE.COM krb_server = myipaserver.example.com plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. TIA On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > On 11/10/2014 02:05 AM, Rolf Nufable wrote: > > Hello > > > > I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > > > > I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. > > I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I > assume this is a problem in SSSD client part, if the user cannot be found. > CCing Lukas and Jakub to advise. Sorry, I skipped this thread b/c the subject didn't look like it was SSSD-related. I think we need to examine SSSD logs... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Tue Nov 11 05:37:17 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Mon, 10 Nov 2014 21:37:17 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> Message-ID: <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: well I'll try them now, my sssd config only consists of these lines added to the sudo area sudo_provider = ldap ldap_uri = ldap://myipaserver.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/myipaserver.example.com ldap_sasl_realm = EXAMPLE.COM krb_server = myipaserver.example.com plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. TIA On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > On 11/10/2014 02:05 AM, Rolf Nufable wrote: > > Hello > > > > I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > > > > I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. > > I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I > assume this is a problem in SSSD client part, if the user cannot be found. > CCing Lukas and Jakub to advise. Sorry, I skipped this thread b/c the subject didn't look like it was SSSD-related. I think we need to examine SSSD logs... -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 11 05:52:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 07:52:22 +0200 Subject: [Freeipa-users] Possible trust issues In-Reply-To: <20141111000118.6008977.95066.7974@gmail.com> References: <20141110220402.6008977.15908.7965@gmail.com> <20141111000118.6008977.95066.7974@gmail.com> Message-ID: <20141111055222.GA19156@redhat.com> On Mon, 10 Nov 2014, William Muriithi wrote: >less /var/log/sssd/sssd_example.loc.log > >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working' >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [set_server_common_status] (0x0100): Marking server 'ipa3-yyz-int.example.loc' as 'working' >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > >Does this mean I have to recreate the trust relationship? ?I didn't get >any error when I set up the trust last week and uncertain recreating >the trust would help. ?Would highly appreciate any pointers on what >would be best way forward. 's2n exop request failed' above tells that communication to IPA master didn't succeed in looking up AD users and groups. You need to enable debug in sssd on IPA master and provide logs from there. -- / Alexander Bokovoy From mkosek at redhat.com Tue Nov 11 06:56:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 07:56:14 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> Message-ID: <5461B30E.8080108@redhat.com> On 11/11/2014 06:37 AM, Rolf Nufable wrote: > or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to deploy, on the contrary, it should be much cooler than 3.3. > On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: > > > > well I'll try them now, my sssd config only consists of these lines added to the sudo area > > sudo_provider = ldap > ldap_uri = ldap://myipaserver.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/myipaserver.example.com > ldap_sasl_realm = EXAMPLE.COM > krb_server = myipaserver.example.com BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo provider. Actually, FreeIPA 4.0+ clients do that for you. More info here: https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf https://fedorahosted.org/freeipa/ticket/3358 > plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. Are you sure that network.negotiate-auth.trusted-uris in about:config correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what is the setting of network.negotiate-auth.trusted-uris? In any case, it is still hard to advise as I still did not see any related logs, error messages or actual real errors preventing you from enrolling FreeIPA. Thanks, Martin > > > TIA > > > > On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: > > > > On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > >> On 11/10/2014 02:05 AM, Rolf > Nufable wrote: >>> Hello >>> >>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>> >>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >> >> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >> assume this is a problem in SSSD client part, if the user cannot be found. >> CCing Lukas and Jakub to advise. > > Sorry, I skipped this thread b/c the subject didn't look like it was > SSSD-related. > > I think we need to examine SSSD logs... > From rolf_16_nufable at yahoo.com Tue Nov 11 07:07:50 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Mon, 10 Nov 2014 23:07:50 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5461B30E.8080108@redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> Message-ID: <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> well I dont know how or what command to use to display the logs, could you teach me how? , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only while on the client side, even though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. TIA On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: On 11/11/2014 06:37 AM, Rolf Nufable wrote: > or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to deploy, on the contrary, it should be much cooler than 3.3. > On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: > > > > well I'll try them now, my sssd config only consists of these lines added to the sudo area > > sudo_provider = ldap > ldap_uri = ldap://myipaserver.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/myipaserver.example.com > ldap_sasl_realm = EXAMPLE.COM > krb_server = myipaserver.example.com BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo provider. Actually, FreeIPA 4.0+ clients do that for you. More info here: https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf https://fedorahosted.org/freeipa/ticket/3358 > plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. Are you sure that network.negotiate-auth.trusted-uris in about:config correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what is the setting of network.negotiate-auth.trusted-uris? In any case, it is still hard to advise as I still did not see any related logs, error messages or actual real errors preventing you from enrolling FreeIPA. Thanks, Martin > > > TIA > > > > On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: > > > > On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > >> On 11/10/2014 02:05 AM, Rolf > Nufable wrote: >>> Hello >>> >>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>> >>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >> >> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >> assume this is a problem in SSSD client part, if the user cannot be found. >> CCing Lukas and Jakub to advise. > > Sorry, I skipped this thread b/c the subject didn't look like it was > SSSD-related. > > I think we need to examine SSSD logs... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 11 07:28:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 08:28:22 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: <5461BA96.1070805@redhat.com> On 11/11/2014 08:07 AM, Rolf Nufable wrote: > well I dont know how or what command to use to display the logs, could you teach me how? There should be HOWTO articles on how to do that. Jakub may have better sources, but I see for example: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > while on the client side, even though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, if SSO login fails. Does at least this part work? Because if not, there is some error on the server side. It would be interesting to check if there are no errors on the server in following logs: - /var/log/httpd/error_log - /var/log/krb5kdc.log > > TIA > > > On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: > > > > On 11/11/2014 06:37 AM, Rolf Nufable wrote: >> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache > > Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to > deploy, on the contrary, it should be much cooler than 3.3. > >> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >> >> >> >> well I'll try them now, my sssd config only consists of these lines added to the sudo area >> >> sudo_provider = ldap >> ldap_uri = ldap://myipaserver.example.com >> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/myipaserver.example.com >> ldap_sasl_realm = EXAMPLE.COM >> krb_server = myipaserver.example.com > > BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo > provider. Actually, FreeIPA 4.0+ clients do that for you. > > More info here: > https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > https://fedorahosted.org/freeipa/ticket/3358 > >> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. > > Are you sure that network.negotiate-auth.trusted-uris in about:config > correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but > not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what > is the setting of network.negotiate-auth.trusted-uris? > > In any case, it is still hard to advise as I still did not see any related > logs, error messages or actual real errors preventing you from enrolling FreeIPA. > > Thanks, > Martin > > >> >> >> TIA >> >> >> >> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >> >> >> >> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >> >>> On 11/10/2014 02:05 AM, Rolf >> Nufable wrote: >>>> Hello >>>> >>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>> >>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >>> >>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>> assume this is a problem in SSSD client part, if the user cannot be found. >>> CCing Lukas and Jakub to advise. >> >> Sorry, I skipped this thread b/c the subject didn't look like it was >> SSSD-related. >> >> I think we need to examine SSSD logs... >> From rolf_16_nufable at yahoo.com Tue Nov 11 07:45:42 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Mon, 10 Nov 2014 23:45:42 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5461BA96.1070805@redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> Message-ID: <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either you are on the server or client side, or at least thats what I remember. Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: On 11/11/2014 08:07 AM, Rolf Nufable wrote: > well I dont know how or what command to use to display the logs, could you teach me how? There should be HOWTO articles on how to do that. Jakub may have better sources, but I see for example: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > while on the client side, even though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, if SSO login fails. Does at least this part work? Because if not, there is some error on the server side. It would be interesting to check if there are no errors on the server in following logs: - /var/log/httpd/error_log - /var/log/krb5kdc.log > > TIA > > > On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: > > > > On 11/11/2014 06:37 AM, Rolf Nufable wrote: >> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache > > Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to > deploy, on the contrary, it should be much cooler than 3.3. > >> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >> >> >> >> well I'll try them now, my sssd config only consists of these lines added to the sudo area >> >> sudo_provider = ldap >> ldap_uri = ldap://myipaserver.example.com >> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/myipaserver.example.com >> ldap_sasl_realm = EXAMPLE.COM >> krb_server = myipaserver.example.com > > BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo > provider. Actually, FreeIPA 4.0+ clients do that for you. > > More info here: > https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > https://fedorahosted.org/freeipa/ticket/3358 > >> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. > > Are you sure that network.negotiate-auth.trusted-uris in about:config > correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but > not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what > is the setting of network.negotiate-auth.trusted-uris? > > In any case, it is still hard to advise as I still did not see any related > logs, error messages or actual real errors preventing you from enrolling FreeIPA. > > Thanks, > Martin > > >> >> >> TIA >> >> >> >> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >> >> >> >> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >> >>> On 11/10/2014 02:05 AM, Rolf >> Nufable wrote: >>>> Hello >>>> >>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>> >>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >>> >>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>> assume this is a problem in SSSD client part, if the user cannot be found. >>> CCing Lukas and Jakub to advise. >> >> Sorry, I skipped this thread b/c the subject didn't look like it was >> SSSD-related. >> >> I think we need to examine SSSD logs... >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Tue Nov 11 07:48:18 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 11 Nov 2014 08:48:18 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: <20141110161934.GA13814@redhat.com> References: <20141110161934.GA13814@redhat.com> Message-ID: Hi Nalin, On Mon, Nov 10, 2014 at 5:19 PM, Nalin Dahyabhai wrote: > On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote: >> How can I debug this? > > First thing would be to run the daemon with additional logging - I > usually use '-d3' to watch what's going on while the daemon's running > various tasks. wow, yes. Now you can debug ;-) I got this sequential message until the certmonger daemon died (unly posting a small portion): 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1020. 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in 1481416576 seconds. 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022. 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022. 2014-11-11 08:34:28 [8610] CA5('local').certs data is unchanged 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs now. 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'ANALYZING' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021. 2014-11-11 08:34:28 [11672] Certificate "Local Signing Authority" valid for 31473673s. 2014-11-11 08:34:28 [11672] Running result is 1481416576. 2014-11-11 08:34:28 [11672] Final result is 1481416576. 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021. 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in 1481416576 seconds. 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING' 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs soon. 2014-11-11 08:34:33 [8610] CA5('local').certs data is unchanged 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs now. 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'ANALYZING' 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022. 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority" valid for 31473668s. 2014-11-11 08:34:33 [11677] Running result is 1481416576. 2014-11-11 08:34:33 [11677] Final result is 1481416576. 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022. 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs in 1481416576 seconds. 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'REFRESHING' 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs soon. 2014-11-11 08:34:38 [8610] CA5('local').certs data is unchanged 2014-11-11 08:34:38 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' 2014-11-11 08:34:38 [8610] Will revisit CA5('local').certs now. Killed > The data logged with the Decoding Error looks like a certificate that's > been base64-encoded, and then base64-encoded again, which is very odd, > since that error message is logged in cases where it fails to parse a > root certificate that it has just retrieved from the CA, and that data > shouldn't have been mangled like that. > > Can you check the contents of the "caCertificate" attribute in the > "cn=cacert,cn=ipa,cn=etc" entry under the IPA base DN in the directory > server, and perhaps provide them? They can be retrieved using a command > like: > ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI caCertificate > > The attribute values are supposed to be certificates in binary form, > which ldapsearch will likely base64-encode for display -- ldapsearch > will indicate that it's doing this by separating the attribute name from > the value using two colons ('::') instead of the usual one (':') in its > output, in accordance with ldif(5). using the apache directory studio I see in the attr cacertificate;binary: invalid certificate (1240 bytes). Using your command I get: $ ldapsearch -b cn=cacert,cn=ipa,cn=etc,dc=domain,dc=tld -Y GSSAPI caCertificate -h kdc01.domain.tld SASL/GSSAPI authentication started SASL username: user.admin at DOMAIN.TLD SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: caCertificate # # CACert, ipa, etc, domain.tld dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1 STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ 2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW 5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU 0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE 9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM 5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY 0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2 NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ== # search result search: 4 result: 0 Success So there is something wrong but how come I only see this in this client after upgrading it to centos 6.6? Thanks for your assistance. Regards, -- -- Groeten, natxo From sbose at redhat.com Tue Nov 11 08:26:27 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Nov 2014 09:26:27 +0100 Subject: [Freeipa-users] Possible trust issues In-Reply-To: <20141111055222.GA19156@redhat.com> References: <20141110220402.6008977.15908.7965@gmail.com> <20141111000118.6008977.95066.7974@gmail.com> <20141111055222.GA19156@redhat.com> Message-ID: <20141111082627.GD7574@localhost.localdomain> On Tue, Nov 11, 2014 at 07:52:22AM +0200, Alexander Bokovoy wrote: > On Mon, 10 Nov 2014, William Muriithi wrote: > >less /var/log/sssd/sssd_example.loc.log > > > >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working' > >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [set_server_common_status] (0x0100): Marking server 'ipa3-yyz-int.example.loc' as 'working' > >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=wmuriithi] > >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > > > >Does this mean I have to recreate the trust relationship? ?I didn't get > >any error when I set up the trust last week and uncertain recreating > >the trust would help. ?Would highly appreciate any pointers on what > >would be best way forward. > 's2n exop request failed' above tells that communication to IPA master > didn't succeed in looking up AD users and groups. You need to enable > debug in sssd on IPA master and provide logs from there. Can you resolve the user on the IPA master? Does ssh work in the IPA master? bye, Sumit > > -- > / 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 From rolf_16_nufable at yahoo.com Tue Nov 11 08:32:53 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 11 Nov 2014 00:32:53 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> Message-ID: <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> never mind the problem on the server side, somehow it got fixed , I really don't know how though so in the client side , It is successful when installing free ipa client and the server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) So I really don't know why Can't I connect to the ipa server. Iptables works fine. /etc/resolv.conf is file as well sssd/sssd.conf ( added these lines ) [sudo] sudo_provider = ldap ldap_uri = ldap://myipaserver.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/myipaserver.example.com ldap_sasl_realm = EXAMPLE.COM krb_server = myipaserver.example.com and /etc/nsswitch.conf (added this line ) sudoers : files sss ldap is there something missing ? On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either you are on the server or client side, or at least thats what I remember. Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: On 11/11/2014 08:07 AM, Rolf Nufable wrote: > well I dont know how or what command to use to display the logs, could you teach me how? There should be HOWTO articles on how to do that. Jakub may have better sources, but I see for example: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > while on the client side, even though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, if SSO login fails. Does at least this part work? Because if not, there is some error on the server side. It would be interesting to check if there are no errors on the server in following logs: - /var/log/httpd/error_log - /var/log/krb5kdc.log > > TIA > > > On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: > > > > On 11/11/2014 06:37 AM, Rolf Nufable wrote: >> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache > > Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to > deploy, on the contrary, it should be much cooler than 3.3. > >> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >> >> >> >> well I'll try them now, my sssd config only consists of these lines added to the sudo area >> >> sudo_provider = ldap >> ldap_uri = ldap://myipaserver.example.com >> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/myipaserver.example.com >> ldap_sasl_realm = EXAMPLE.COM >> krb_server = myipaserver.example.com > > BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo > provider. Actually, FreeIPA 4.0+ clients do that for you. > > More info here: > https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > https://fedorahosted.org/freeipa/ticket/3358 > >> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. > > Are you sure that network.negotiate-auth.trusted-uris in about:config > correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but > not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what > is the setting of network.negotiate-auth.trusted-uris? > > In any case, it is still hard to advise as I still did not see any related > logs, error messages or actual real errors preventing you from enrolling FreeIPA. > > Thanks, > Martin > > >> >> >> TIA >> >> >> >> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >> >> >> >> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >> >>> On 11/10/2014 02:05 AM, Rolf >> Nufable wrote: >>>> Hello >>>> >>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>> >>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >>> >>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>> assume this is a problem in SSSD client part, if the user cannot be found. >>> CCing Lukas and Jakub to advise. >> >> Sorry, I skipped this thread b/c the subject didn't look like it was >> SSSD-related. >> >> I think we need to examine SSSD logs... >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 11 09:56:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 10:56:16 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> Message-ID: <5461DD40.6060507@redhat.com> It is still really hard to give advise as I do not know what's actually wrong. So are you trying to set up a sudo on your client or are you trying to log in with your client browser to FreeIPA server? These are 2 orthogonal actions. Who gives the "Can't I connect to the ipa server" error? As I said earlier, I cannot help you without described procedure you are trying to do, logs and exact error messages. Martin On 11/11/2014 09:32 AM, Rolf Nufable wrote: > never mind the problem on the server side, somehow it got fixed , I really don't know how though > > so in the client side , It is successful when installing free ipa client and the server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) > > So I really don't know why Can't I connect to the ipa server. > > Iptables works fine. > /etc/resolv.conf is file as well > > sssd/sssd.conf ( added these lines ) > [sudo] > sudo_provider = ldap > ldap_uri = ldap://myipaserver.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/myipaserver.example.com > ldap_sasl_realm = EXAMPLE.COM > krb_server = myipaserver.example.com > > > and /etc/nsswitch.conf > (added this line ) > > sudoers : files sss ldap > > is there something missing ? > > > > On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: > > > > oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either you are on the server or client side, or at least thats what I remember. > > Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs > > > > > On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: > > > > On 11/11/2014 08:07 AM, Rolf Nufable wrote: >> well I dont know how or what command to use to display the logs, could you teach me how? > > There should be HOWTO articles on how to do that. Jakub may have better > sources, but I see for example: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > >> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only > > network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > >> while on the client side, even > though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. > > FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, > if SSO login fails. Does at least this part work? Because if not, there is some > error on the server side. It would be interesting to check if there are no > errors on the server in following logs: > - /var/log/httpd/error_log > - /var/log/krb5kdc.log > > > >> >> TIA >> >> >> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >> >> >> >> On 11/11/2014 06:37 AM, Rolf Nufable wrote: >>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >> >> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >> deploy, on the > contrary, it should be much cooler than 3.3. >> >>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>> >>> >>> >>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>> >>> sudo_provider = ldap >>> ldap_uri = ldap://myipaserver.example.com >>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>> ldap_sasl_mech = > GSSAPI >>> ldap_sasl_authid = host/myipaserver.example.com >>> ldap_sasl_realm = EXAMPLE.COM >>> krb_server = myipaserver.example.com >> >> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >> provider. Actually, FreeIPA 4.0+ clients do that for you. >> >> More info here: >> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> https://fedorahosted.org/freeipa/ticket/3358 >> >>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >> >> Are you sure that network.negotiate-auth.trusted-uris in about:config >> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >> is the setting of network.negotiate-auth.trusted-uris? >> >> In any case, it is still hard to > advise as I still did not see any related >> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >> >> Thanks, >> Martin >> >> >>> >>> >>> TIA >>> >>> >>> >>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>> >>> >>> >>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>> >>>> On 11/10/2014 02:05 AM, Rolf >>> Nufable wrote: >>>>> Hello >>>>> >>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>> >>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it > in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >>>> >>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>> CCing Lukas and Jakub to advise. >>> >>> Sorry, I skipped this thread b/c the subject didn't look like it was >>> SSSD-related. >>> >>> I think we need to examine SSSD logs... >>> From rolf_16_nufable at yahoo.com Tue Nov 11 10:07:57 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 11 Nov 2014 02:07:57 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5461DD40.6060507@redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461DD40.6060507@redhat.com> Message-ID: <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) well I'm having this error in the client side when using the command su - ( user ) su - user at example.com su : user at example.com does not exist. On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: It is still really hard to give advise as I do not know what's actually wrong. So are you trying to set up a sudo on your client or are you trying to log in with your client browser to FreeIPA server? These are 2 orthogonal actions. Who gives the "Can't I connect to the ipa server" error? As I said earlier, I cannot help you without described procedure you are trying to do, logs and exact error messages. Martin On 11/11/2014 09:32 AM, Rolf Nufable wrote: > never mind the problem on the server side, somehow it got fixed , I really don't know how though > > so in the client side , It is successful when installing free ipa client and the server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) > > So I really don't know why Can't I connect to the ipa server. > > Iptables works fine. > /etc/resolv.conf is file as well > > sssd/sssd.conf ( added these lines ) > [sudo] > sudo_provider = ldap > ldap_uri = ldap://myipaserver.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/myipaserver.example.com > ldap_sasl_realm = EXAMPLE.COM > krb_server = myipaserver.example.com > > > and /etc/nsswitch.conf > (added this line ) > > sudoers : files sss ldap > > is there something missing ? > > > > On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: > > > > oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either you are on the server or client side, or at least thats what I remember. > > Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs > > > > > On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: > > > > On 11/11/2014 08:07 AM, Rolf Nufable wrote: >> well I dont know how or what command to use to display the logs, could you teach me how? > > There should be HOWTO articles on how to do that. Jakub may have better > sources, but I see for example: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > >> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only > > network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > >> while on the client side, even > though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. > > FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, > if SSO login fails. Does at least this part work? Because if not, there is some > error on the server side. It would be interesting to check if there are no > errors on the server in following logs: > - /var/log/httpd/error_log > - /var/log/krb5kdc.log > > > >> >> TIA >> >> >> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >> >> >> >> On 11/11/2014 06:37 AM, Rolf Nufable wrote: >>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >> >> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >> deploy, on the > contrary, it should be much cooler than 3.3. >> >>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>> >>> >>> >>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>> >>> sudo_provider = ldap >>> ldap_uri = ldap://myipaserver.example.com >>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>> ldap_sasl_mech = > GSSAPI >>> ldap_sasl_authid = host/myipaserver.example.com >>> ldap_sasl_realm = EXAMPLE.COM >>> krb_server = myipaserver.example.com >> >> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >> provider. Actually, FreeIPA 4.0+ clients do that for you. >> >> More info here: >> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> https://fedorahosted.org/freeipa/ticket/3358 >> >>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >> >> Are you sure that network.negotiate-auth.trusted-uris in about:config >> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >> is the setting of network.negotiate-auth.trusted-uris? >> >> In any case, it is still hard to > advise as I still did not see any related >> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >> >> Thanks, >> Martin >> >> >>> >>> >>> TIA >>> >>> >>> >>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>> >>> >>> >>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>> >>>> On 11/10/2014 02:05 AM, Rolf >>> Nufable wrote: >>>>> Hello >>>>> >>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>> >>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it > in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. >>>> >>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>> CCing Lukas and Jakub to advise. >>> >>> Sorry, I skipped this thread b/c the subject didn't look like it was >>> SSSD-related. >>> >>> I think we need to examine SSSD logs... >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 11 10:09:15 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Nov 2014 11:09:15 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5461B30E.8080108@redhat.com> References: <1415581536.59772.YahooMailNeo@web161605.mail.bf1.yahoo.com> <5460A7D0.5060203@redhat.com> <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> Message-ID: <20141111100915.GL14216@hendrix.redhat.com> On Tue, Nov 11, 2014 at 07:56:14AM +0100, Martin Kosek wrote: > On 11/11/2014 06:37 AM, Rolf Nufable wrote: > > or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache > > Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to > deploy, on the contrary, it should be much cooler than 3.3. > > > On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: > > > > > > > > well I'll try them now, my sssd config only consists of these lines added to the sudo area > > > > sudo_provider = ldap > > ldap_uri = ldap://myipaserver.example.com > > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > > ldap_sasl_mech = GSSAPI > > ldap_sasl_authid = host/myipaserver.example.com > > ldap_sasl_realm = EXAMPLE.COM > > krb_server = myipaserver.example.com > > BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo > provider. Actually, FreeIPA 4.0+ clients do that for you. Right, in addition, the above should have been added to the domain section, not the sudo section with older clients.. > > More info here: > https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > https://fedorahosted.org/freeipa/ticket/3358 > > > plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. > > Are you sure that network.negotiate-auth.trusted-uris in about:config > correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but > not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what > is the setting of network.negotiate-auth.trusted-uris? > > In any case, it is still hard to advise as I still did not see any related > logs, error messages or actual real errors preventing you from enrolling FreeIPA. > > Thanks, > Martin > > > > > > > TIA > > > > > > > > On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: > > > > > > > > On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > > > >> On 11/10/2014 02:05 AM, Rolf > > Nufable wrote: > >>> Hello > >>> > >>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > >>> > >>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question is how can I solve this problem?? I've been at it for 3 weeks now .. > >> > >> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I > >> assume this is a problem in SSSD client part, if the user cannot be found. > >> CCing Lukas and Jakub to advise. > > > > Sorry, I skipped this thread b/c the subject didn't look like it was > > SSSD-related. > > > > I think we need to examine SSSD logs... > > > From jhrozek at redhat.com Tue Nov 11 10:11:06 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Nov 2014 11:11:06 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> References: <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461DD40.6060507@redhat.com> <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> Message-ID: <20141111101106.GM14216@hendrix.redhat.com> On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: > well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) > > well I'm having this error in the client side when using the command su - ( user ) > > su - user at example.com > > su : user at example.com does not exist. Are you sure ipa-client-install did run successfully on that machine? Can you unenroll and enroll the client back so that we start from an sssd.conf that is created by the tooling? As Martin said, you don't need those sudo-related config options with recent SSSD releases, they wouldn't work in the sudo section anyway. > > > > On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: > > > > It is still really hard to give advise as I do not know what's actually wrong. > So are you trying to set up a sudo on your client or are you trying to log in > with your client browser to FreeIPA server? These are 2 orthogonal actions. > > Who gives the "Can't I connect to the ipa server" error? As I said earlier, I > cannot help you without described procedure you are trying to do, logs and > exact error messages. > > Martin > > > On 11/11/2014 09:32 AM, Rolf Nufable wrote: > > never mind the problem on the server side, somehow it got fixed , I really don't know how though > > > > so in the client side , It is successful when installing free ipa client and the > server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) > > > > So I really don't know why Can't I connect to the ipa server. > > > > Iptables works fine. > > /etc/resolv.conf is file as well > > > > sssd/sssd.conf ( added these lines ) > > [sudo] > > sudo_provider = ldap > > ldap_uri = ldap://myipaserver.example.com > > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > > ldap_sasl_mech = GSSAPI > > ldap_sasl_authid = host/myipaserver.example.com > > ldap_sasl_realm = EXAMPLE.COM > > krb_server = myipaserver.example.com > > > > > > and /etc/nsswitch.conf > > (added this line ) > > > > sudoers : files sss ldap > > > > is there something missing ? > > > > > > > > On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: > > > > > > > > oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either > you are on the server or client side, or at least thats what I remember. > > > > Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs > > > > > > > > > > On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: > > > > > > > > On 11/11/2014 08:07 AM, Rolf Nufable wrote: > >> well I dont know how or what command to use to display the logs, could you teach me how? > > > > There should be HOWTO articles on how to do that. Jakub may have better > > sources, but I see for > example: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > > > >> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only > > > > network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. > > > >> while on the client side, even > > though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. > > > > FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, > > if SSO login fails. Does at least this part work? Because if not, there is some > > error on the server side. It would be interesting to check if there are no > > errors on the server in following logs: > > - /var/log/httpd/error_log > > - /var/log/krb5kdc.log > > > > > > > >> > >> TIA > >> > >> > >> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: > >> > >> > >> > >> On 11/11/2014 06:37 AM, Rolf Nufable > wrote: > >>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache > >> > >> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to > >> deploy, on the > > contrary, it should be much cooler than 3.3. > >> > >>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: > >>> > >>> > >>> > >>> well I'll try them now, my sssd config only consists of these lines added to the sudo area > >>> > >>> sudo_provider = ldap > >>> ldap_uri = ldap://myipaserver.example.com > >>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > >>> ldap_sasl_mech = > > GSSAPI > >>> ldap_sasl_authid = host/myipaserver.example.com > >>> ldap_sasl_realm = EXAMPLE.COM > >>> krb_server = myipaserver.example.com > >> > >> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo > >> provider. Actually, FreeIPA 4.0+ clients do that for you. > >> > >> More info here: > >> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >> https://fedorahosted.org/freeipa/ticket/3358 > >> > >>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. > >> > >> Are you sure that network.negotiate-auth.trusted-uris in about:config > >> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but > >> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what > >> is the setting of network.negotiate-auth.trusted-uris? > >> > >> In any case, it is still hard to > > advise as I still did not see any related > >> logs, error messages or actual real errors preventing you from enrolling FreeIPA. > >> > >> Thanks, > >> Martin > >> > >> > >>> > >>> > >>> TIA > >>> > >>> > >>> > >>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: > >>> > >>> > >>> > >>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: > >>> > >>>> On 11/10/2014 02:05 AM, Rolf > >>> Nufable wrote: > >>>>> Hello > >>>>> > >>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . > >>>>> > >>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it > > in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question > is how can I solve this problem?? I've been at it for 3 weeks now .. > >>>> > >>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I > >>>> assume this is a problem in SSSD client part, if the user cannot be found. > >>>> CCing Lukas and Jakub to advise. > >>> > >>> Sorry, I skipped this thread b/c the subject didn't look like it was > >>> SSSD-related. > >>> > >>> I think we need to examine SSSD logs... > >>> From mkosek at redhat.com Tue Nov 11 11:01:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 12:01:59 +0100 Subject: [Freeipa-users] strange error deleting replica? In-Reply-To: <5460FCB7.3060309@gmail.com> References: <5460FCB7.3060309@gmail.com> Message-ID: <5461ECA7.6000203@redhat.com> On 11/10/2014 06:58 PM, Janelle wrote: > Hi -- > > Has anyone seen this before? > > # ipa-replica-manage del kermit.xyzzy.com --force > unexpected error: [Errno -2] Name or service not known > > ?? Very confused as to What service or name is not known? > > This is 4.0.5 running on CentOS 7. > > ~J This is usually DNS resolution error, though the command should not crash this way. Does follow resolution work? $ host `hostname` $ host kermit.xyzzy.com Alternatively, if you are not sure which DNS resolution fails, we could look at strace output: $ strace -o ipa.strace ipa-replica-manage del kermit.xyzzy.com --force That would create a log caled ipa.strace with all system calls of ipa-replica-manage del command and we would see which DNS resolution failed. Martin From pvoborni at redhat.com Tue Nov 11 11:10:51 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Nov 2014 12:10:51 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <20141111101106.GM14216@hendrix.redhat.com> References: <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461DD40.6060507@redhat.com> <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> <20141111101106.GM14216@hendrix.redhat.com> Message-ID: <5461EEBB.2020402@redhat.com> On 11.11.2014 11:11, Jakub Hrozek wrote: > On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: >> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) >> >> well I'm having this error in the client side when using the command su - ( user ) >> >> su - user at example.com >> >> su : user at example.com does not exist. > > Are you sure ipa-client-install did run successfully on that machine? > > Can you unenroll and enroll the client back so that we start from an > sssd.conf that is created by the tooling? > > As Martin said, you don't need those sudo-related config options with > recent SSSD releases, they wouldn't work in the sudo section anyway. Does: $ id user at example.com return you the user info? if not and ipa-client-install was run successfully before, check nsswitch.conf if it has sssd configured (sss next to various providers). if not run: $ authconfig --enablesssd --update if it doesn't help, try to run: $ authconfig --disablesssd --update $ authconfig --enablesssd --update if it helps, please tell me. I'm curious if you suffer from one issue I experienced. > >> >> >> >> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: >> >> >> >> It is still really hard to give advise as I do not know what's actually wrong. >> So are you trying to set up a sudo on your client or are you trying to log in >> with your client browser to FreeIPA server? These are 2 orthogonal actions. >> >> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I >> cannot help you without described procedure you are trying to do, logs and >> exact error messages. >> >> Martin >> >> >> On 11/11/2014 09:32 AM, Rolf Nufable wrote: >>> never mind the problem on the server side, somehow it got fixed , I really don't know how though >>> >>> so in the client side , It is successful when installing free ipa client and the >> server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) >>> >>> So I really don't know why Can't I connect to the ipa server. >>> >>> Iptables works fine. >>> /etc/resolv.conf is file as well >>> >>> sssd/sssd.conf ( added these lines ) >>> [sudo] >>> sudo_provider = ldap >>> ldap_uri = ldap://myipaserver.example.com >>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>> ldap_sasl_mech = GSSAPI >>> ldap_sasl_authid = host/myipaserver.example.com >>> ldap_sasl_realm = EXAMPLE.COM >>> krb_server = myipaserver.example.com >>> >>> >>> and /etc/nsswitch.conf >>> (added this line ) >>> >>> sudoers : files sss ldap >>> >>> is there something missing ? >>> >>> >>> >>> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: >>> >>> >>> >>> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either >> you are on the server or client side, or at least thats what I remember. >>> >>> Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs >>> >>> >>> >>> >>> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: >>> >>> >>> >>> On 11/11/2014 08:07 AM, Rolf Nufable wrote: >>>> well I dont know how or what command to use to display the logs, could you teach me how? >>> >>> There should be HOWTO articles on how to do that. Jakub may have better >>> sources, but I see for >> example: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html >>> >>>> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only >>> >>> network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. >>> >>>> while on the client side, even >>> though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. >>> >>> FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, >>> if SSO login fails. Does at least this part work? Because if not, there is some >>> error on the server side. It would be interesting to check if there are no >>> errors on the server in following logs: >>> - /var/log/httpd/error_log >>> - /var/log/krb5kdc.log >>> >>> >>> >>>> >>>> TIA >>>> >>>> >>>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >>>> >>>> >>>> >>>> On 11/11/2014 06:37 AM, Rolf Nufable >> wrote: >>>>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >>>> >>>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >>>> deploy, on the >>> contrary, it should be much cooler than 3.3. >>>> >>>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>>>> >>>>> >>>>> >>>>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>>>> >>>>> sudo_provider = ldap >>>>> ldap_uri = ldap://myipaserver.example.com >>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>> ldap_sasl_mech = >>> GSSAPI >>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>> ldap_sasl_realm = EXAMPLE.COM >>>>> krb_server = myipaserver.example.com >>>> >>>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >>>> provider. Actually, FreeIPA 4.0+ clients do that for you. >>>> >>>> More info here: >>>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>> https://fedorahosted.org/freeipa/ticket/3358 >>>> >>>>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >>>> >>>> Are you sure that network.negotiate-auth.trusted-uris in about:config >>>> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >>>> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >>>> is the setting of network.negotiate-auth.trusted-uris? >>>> >>>> In any case, it is still hard to >>> advise as I still did not see any related >>>> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >>>> >>>> Thanks, >>>> Martin >>>> >>>> >>>>> >>>>> >>>>> TIA >>>>> >>>>> >>>>> >>>>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>>>> >>>>>> On 11/10/2014 02:05 AM, Rolf >>>>> Nufable wrote: >>>>>>> Hello >>>>>>> >>>>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>>>> >>>>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it >>> in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question >> is how can I solve this problem?? I've been at it for 3 weeks now .. >>>>>> >>>>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>>>> CCing Lukas and Jakub to advise. >>>>> >>>>> Sorry, I skipped this thread b/c the subject didn't look like it was >>>>> SSSD-related. >>>>> >>>>> I think we need to examine SSSD logs... >>>>> -- Petr Vobornik From mbasti at redhat.com Tue Nov 11 11:19:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 12:19:35 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> Message-ID: <5461F0C7.4010208@redhat.com> IMHO It's DS bug, can you share DS error log? pspacek CCed to examine named logs. Martin^2 On 11/11/14 12:13, Walter van Lille wrote: > Hi Martin, thanks for the reply. > My version: bind-dyndb-ldap-2.3-5.el6.x86_64 > The server doesn't have journalctl installed but I have the outputs > from the messages and named.run files that I included here: > > Messages: > > *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) > resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* > *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to > adjust "timeout" parameter* > *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to > adjust "timeout" parameter* > *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to > adjust "timeout" parameter* > *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to > adjust "timeout" parameter* > > Named.run: > > *client 10.123.123.123#42639: transfer of 'example.example/IN': > AXFR-style IXFR started* > *client 10.123.123.123#42639: transfer of ''example.example/IN': > AXFR-style IXFR ended* > *client 10.123.123.123#46912: transfer of > '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* > *client 10.123.123.123#46912: transfer of > '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* > *LDAP query timed out. Try to adjust "timeout" parameter* > *LDAP query timed out. Try to adjust "timeout" parameter* > *LDAP query timed out. Try to adjust "timeout" parameter* > > I just replaced the IPs and the actual names with something more generic. > > Regards, > > Walter > > On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti > wrote: > > On 06/11/14 14:58, Walter van Lille wrote: >> Hi, >> >> I need some assistance please. >> I've taken over an IPA server to manage a few months ago, and it >> was working fine until recently when it started acting up >> seemingly off its own accord. >> When I do an ipactl status it basically gives an output as shown >> below: >> >> >> *Directory Service: RUNNING >> * >> * >> * >> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... >> (To the tune of 7 minutes sometimes)* >> * >> * >> *KDC Service: RUNNING* >> *KPASSWD Service: RUNNING* >> *DNS Service: RUNNING* >> *MEMCACHE Service: RUNNING* >> *HTTP Service: RUNNING* >> *CA Service: RUNNING* >> *ADTRUST Service: RUNNING* >> *EXTID Service: RUNNING* >> >> Running top showed that ns-slapd was munching almost all my >> resources, but I got that fixed by upping the cache. >> Unfortunately this did not correct the issue and it still reacts >> in the same fashion, although the resources have been freed up now. >> I've noticed that when I run dig on either the local server or a >> remote machine that the query basically just times out as shown here: >> >> *dig freeipa.myexample.sample* >> * >> * >> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >> freeipa.myexample.sample* >> *;; global options: +cmd* >> *;; connection timed out; no servers could be reached* >> >> When the KDC service fails to start, then name lookups seem OK, >> but authentication fails. otherwise it's dead in the water. >> >> This also happens: >> >> *sudo ipactl status* >> *Directory Service: RUNNING* >> *Unknown error when retrieving list of services from LDAP:* >> * >> * >> My software setup is as follows: >> >> *CentOS release 6.5 (Final) >> * >> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >> * >> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >> * >> *bind-dyndb-ldap.x86_64* >> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *rpcbind.x86_64 0.2.0-11.el6 >> @anaconda-CentOS-201311291202.x86_64/6.5* >> *samba4-winbind.x86_64* >> *krb5-server.x86_64 1.10.3-15.el6_5.1 >> * >> * >> * >> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC >> 2014 x86_64 x86_64 x86_64 GNU/Linux >> * >> >> It's not a permanent situation as it sometimes runs 100% for a >> while, but 80% of the time it is unusable. If anybody can assist >> me, please be so kind. >> >> Regards, >> >> Walter >> > Hello please which version of bind-dyndb-ldap do you use? > I had similar issue with bind-dyndb-ldap, but it was development > version, I'm not sure if this is your case. > When named was failing, dirserv was really slow. > > Can you send journalctl -b -u named log when dig doesn't work?? > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman at naumenko.ca Tue Nov 11 11:23:27 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 11 Nov 2014 06:23:27 -0500 Subject: [Freeipa-users] Adjust settings for processes Message-ID: <5461F1AF.2000708@naumenko.ca> I'd like to adjust process settings on freeipa server to fit it better into virtual instance. Is it possible to change settings of java, ns-slapd and apache processes somewhere in config files and what those files are? For example: ServerLimit, StartServers and things like that typically set for apache mpm, but I couldn't find relevant options in /etc/httpd apachectl status httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: active (running) since Sun 2014-10-26 16:19:24 UTC; 1 weeks 5 days ago Main PID: 1546 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service |- 1546 /usr/sbin/httpd -DFOREGROUND |- 1547 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias |-17436 /usr/sbin/httpd -DFOREGROUND |-17437 /usr/sbin/httpd -DFOREGROUND |-17438 /usr/sbin/httpd -DFOREGROUND |-17439 /usr/sbin/httpd -DFOREGROUND |-17440 /usr/sbin/httpd -DFOREGROUND |-17441 /usr/sbin/httpd -DFOREGROUND |-17442 /usr/sbin/httpd -DFOREGROUND |-18416 /usr/sbin/httpd -DFOREGROUND `-22003 /usr/sbin/httpd -DFOREGROUND Nov 06 13:23:03 ipa httpd[17436]: GSSAPI client step 1 Nov 06 13:23:03 ipa httpd[17436]: GSSAPI client step 2 Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1 Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1 Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1 Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 2 Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1 Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1 Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1 Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 2 --Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 11 11:40:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Nov 2014 12:40:07 +0100 Subject: [Freeipa-users] DNS and $GENERATE Directive In-Reply-To: <54607664.5070206@redhat.com> References: <545D52E1.3060005@atcri.com> <54607664.5070206@redhat.com> Message-ID: <5461F597.9050809@redhat.com> On 10.11.2014 09:25, Martin Kosek wrote: > On 11/08/2014 12:16 AM, Andrew Powell wrote: >> Is there a way to add a Bind $GENERATE directive line to FreeIPA to >> automatically name DHCP-assigned ranges? >> >> In a file-based Bind installation, I can have the following line in the forward >> example.com zone file: >> >> $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$ >> >> (which adds records wd080.example.com thru wd250.example.com) >> >> And for the reverse zone (0.168.192.in-addr.arpa) I can have the following line: >> >> $generate 80-250/1 $ PTR wd${0,3,d}.example.com. >> >> I can do without naming the DHCP-assigned ranges, but it seems like the proper >> thing to do. >> > > Interesting question. I do not think bind-dyndb-ldap supports the $GENERATE > directive. I am not even sure how to extend LDAP DNS tree to support it as it > has a very specific syntax. You would need to add a new LDAP space accepting > strings that would be then passed to BIND... I will let Petr to assess if this > is possible or not. We would have to re-implement the $GENERATE logic ourselves (and find a way how to store it in LDAP). It would complicate dynamic updates a lot so I would rather avoid implementing this in bind-dyndb-ldap. > For now, the best approach would be to either add all these records to LDAP or > to have it in a BIND zone file and synchronize between all FreeIPA DNS servers. I would recommend to simply use ipa dnsrecord-add command in a for cycle to add all the records. ipa dnsrecord-generate command could generate set of LDAP objects too and it would not require any changes in bind-dyndb-ldap... But I'm not sure if there is a real benefit. IMHO it would be better to implement https://fedorahosted.org/freeipa/ticket/4706 Seed managed DNS domain from existing domain -- Petr^2 Spacek From abokovoy at redhat.com Tue Nov 11 11:52:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 13:52:09 +0200 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <5461F1AF.2000708@naumenko.ca> References: <5461F1AF.2000708@naumenko.ca> Message-ID: <20141111115209.GD19156@redhat.com> On Tue, 11 Nov 2014, Roman Naumenko wrote: >I'd like to adjust process settings on freeipa server to fit it better >into virtual instance. >Is it possible to change settings of java, ns-slapd and apache >processes somewhere in config files and what those files are? http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service ----------------------- # For example, to pass additional options (for instance, -D definitions) to the # httpd binary at startup, you need to create a file named # "/etc/systemd/system/httpd.service" containing: # .include /lib/systemd/system/httpd.service # [Service] # Environment=OPTIONS=-DMY_DEFINE ----------------------- -- / Alexander Bokovoy From vaclav.adamec at suchy-zleb.cz Tue Nov 11 11:53:58 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 11 Nov 2014 12:53:58 +0100 Subject: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support Message-ID: Hi, I'm getting "Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available" during ipa client install on CentOS 6.6 Packages openssh-server-6.1p1-5.el6.1.x86_64 and ipa-client-3.0.0-42.el6.centos.x86_64 Manual setup of "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" in /etc/ssh/sshd_config is ok. Any reason for that ? Thanks Vasek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 11 11:57:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 12:57:03 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: References: <20141110161934.GA13814@redhat.com> Message-ID: <5461F98F.3050409@redhat.com> On 11/11/2014 08:48 AM, Natxo Asenjo wrote: > Hi Nalin, > > On Mon, Nov 10, 2014 at 5:19 PM, Nalin Dahyabhai wrote: >> On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote: >>> How can I debug this? >> >> First thing would be to run the daemon with additional logging - I >> usually use '-d3' to watch what's going on while the daemon's running >> various tasks. > > wow, yes. Now you can debug ;-) > > I got this sequential message until the certmonger daemon died (unly > posting a small portion): > > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1020. > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in > 1481416576 seconds. > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022. > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022. > 2014-11-11 08:34:28 [8610] CA5('local').certs data is unchanged > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs now. > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'ANALYZING' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021. > 2014-11-11 08:34:28 [11672] Certificate "Local Signing Authority" > valid for 31473673s. > 2014-11-11 08:34:28 [11672] Running result is 1481416576. > 2014-11-11 08:34:28 [11672] Final result is 1481416576. > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021. > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in > 1481416576 seconds. > 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING' > 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs soon. > 2014-11-11 08:34:33 [8610] CA5('local').certs data is unchanged > 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' > 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs now. > 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'ANALYZING' > 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022. > 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority" > valid for 31473668s. > 2014-11-11 08:34:33 [11677] Running result is 1481416576. > 2014-11-11 08:34:33 [11677] Final result is 1481416576. > 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022. > 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH' > 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs in > 1481416576 seconds. > 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'REFRESHING' > 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs soon. > 2014-11-11 08:34:38 [8610] CA5('local').certs data is unchanged > 2014-11-11 08:34:38 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE' > 2014-11-11 08:34:38 [8610] Will revisit CA5('local').certs now. > Killed > >> The data logged with the Decoding Error looks like a certificate that's >> been base64-encoded, and then base64-encoded again, which is very odd, >> since that error message is logged in cases where it fails to parse a >> root certificate that it has just retrieved from the CA, and that data >> shouldn't have been mangled like that. >> >> Can you check the contents of the "caCertificate" attribute in the >> "cn=cacert,cn=ipa,cn=etc" entry under the IPA base DN in the directory >> server, and perhaps provide them? They can be retrieved using a command >> like: >> ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI caCertificate >> >> The attribute values are supposed to be certificates in binary form, >> which ldapsearch will likely base64-encode for display -- ldapsearch >> will indicate that it's doing this by separating the attribute name from >> the value using two colons ('::') instead of the usual one (':') in its >> output, in accordance with ldif(5). > > using the apache directory studio I see in the attr > cacertificate;binary: invalid certificate (1240 bytes). > > Using your command I get: > > $ ldapsearch -b cn=cacert,cn=ipa,cn=etc,dc=domain,dc=tld -Y GSSAPI > caCertificate -h kdc01.domain.tld > SASL/GSSAPI authentication started > SASL username: user.admin at DOMAIN.TLD > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: caCertificate > # > > # CACert, ipa, etc, domain.tld > dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld > cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF > EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK > MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT > WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV > FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF > BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1 > STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ > 2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW > 5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF > XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv > azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd > zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU > 0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN > Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC > QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb > WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE > 9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM > 5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu > d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY > 0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2 > NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV > qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ== > > # search result > search: 4 > result: 0 Success > > So there is something wrong but how come I only see this in this > client after upgrading it to centos 6.6? > > Thanks for your assistance. It is strange, yes. This bug is related to client certificate retrieval, fixed in 6.5: https://bugzilla.redhat.com/show_bug.cgi?id=924004 In 6.5, we also fixed certificate upload on upgrade is it sometimes could have gone double encoded: https://bugzilla.redhat.com/show_bug.cgi?id=948928 So if the lurking double encoded certificate is in LDAP, and thus Apache DS shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way to fix it would be to: - Open your Apache DS - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry - Run # ipa-ldap-updater --upgrade --ldapi --quiet on your 6.5+ server and the certificate entry should get regenerated (tested with 7.0). Martin From walter.van.lille at gmail.com Tue Nov 11 12:13:39 2014 From: walter.van.lille at gmail.com (Walter van Lille) Date: Tue, 11 Nov 2014 14:13:39 +0200 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <5461F0C7.4010208@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> Message-ID: I've just cleaned out a ton of slapd_poll timed out messages from the output and changed the names to protect the innocent, :-) Here is the output as requested: *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds maximum allowed limit (length=805634565, limit=2097152). Change the nsslapd-maxsasliosize attribute in cn=config to increase limit.* *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL security on connection in CLOSING state* *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers from connection* *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling operation threads* *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 threads to terminate* *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down internal subsystems and plugins* *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 B2014.219.179 starting up* *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=sample,dc=example* *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which should be added before the CoS Definition.* *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which should be added before the CoS Definition.* *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests* *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for LDAPS requests* *[11/Nov/2014:13:26:36 +0200] - Listening on /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti wrote: > IMHO It's DS bug, can you share DS error log? > pspacek CCed to examine named logs. > > Martin^2 > > > On 11/11/14 12:13, Walter van Lille wrote: > > Hi Martin, thanks for the reply. > My version: bind-dyndb-ldap-2.3-5.el6.x86_64 > The server doesn't have journalctl installed but I have the outputs from > the messages and named.run files that I included here: > > Messages: > > *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) > resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* > *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust > "timeout" parameter* > *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust > "timeout" parameter* > *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust > "timeout" parameter* > *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust > "timeout" parameter* > > Named.run: > > *client 10.123.123.123#42639: transfer of 'example.example/IN': > AXFR-style IXFR started* > *client 10.123.123.123#42639: transfer of ''example.example/IN': > AXFR-style IXFR ended* > *client 10.123.123.123#46912: transfer of > '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* > *client 10.123.123.123#46912: transfer of > '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* > *LDAP query timed out. Try to adjust "timeout" parameter* > *LDAP query timed out. Try to adjust "timeout" parameter* > *LDAP query timed out. Try to adjust "timeout" parameter* > > I just replaced the IPs and the actual names with something more generic. > > Regards, > > Walter > > On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti wrote: > >> On 06/11/14 14:58, Walter van Lille wrote: >> >> Hi, >> >> I need some assistance please. >> I've taken over an IPA server to manage a few months ago, and it was >> working fine until recently when it started acting up seemingly off its own >> accord. >> When I do an ipactl status it basically gives an output as shown below: >> >> >> >> *Directory Service: RUNNING * >> >> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To the >> tune of 7 minutes sometimes)* >> >> *KDC Service: RUNNING* >> *KPASSWD Service: RUNNING* >> *DNS Service: RUNNING* >> *MEMCACHE Service: RUNNING* >> *HTTP Service: RUNNING* >> *CA Service: RUNNING* >> *ADTRUST Service: RUNNING* >> *EXTID Service: RUNNING* >> >> Running top showed that ns-slapd was munching almost all my resources, >> but I got that fixed by upping the cache. Unfortunately this did not >> correct the issue and it still reacts in the same fashion, although the >> resources have been freed up now. >> I've noticed that when I run dig on either the local server or a remote >> machine that the query basically just times out as shown here: >> >> *dig freeipa.myexample.sample* >> >> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >> freeipa.myexample.sample* >> *;; global options: +cmd* >> *;; connection timed out; no servers could be reached* >> >> When the KDC service fails to start, then name lookups seem OK, but >> authentication fails. otherwise it's dead in the water. >> >> This also happens: >> >> *sudo ipactl status* >> *Directory Service: RUNNING* >> *Unknown error when retrieving list of services from LDAP:* >> >> My software setup is as follows: >> >> >> *CentOS release 6.5 (Final) * >> >> *389-ds-base.x86_64 1.2.11.15-34.el6_5 * >> >> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * >> *bind-dyndb-ldap.x86_64* >> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >> *rpcbind.x86_64 0.2.0-11.el6 >> @anaconda-CentOS-201311291202.x86_64/6.5* >> *samba4-winbind.x86_64* >> >> *krb5-server.x86_64 1.10.3-15.el6_5.1 * >> >> >> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 >> x86_64 x86_64 x86_64 GNU/Linux * >> >> It's not a permanent situation as it sometimes runs 100% for a while, >> but 80% of the time it is unusable. If anybody can assist me, please be so >> kind. >> >> Regards, >> >> Walter >> >> Hello please which version of bind-dyndb-ldap do you use? >> I had similar issue with bind-dyndb-ldap, but it was development version, >> I'm not sure if this is your case. >> When named was failing, dirserv was really slow. >> >> Can you send journalctl -b -u named log when dig doesn't work?? >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Tue Nov 11 12:28:31 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 11 Nov 2014 13:28:31 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: <5461F98F.3050409@redhat.com> References: <20141110161934.GA13814@redhat.com> <5461F98F.3050409@redhat.com> Message-ID: hi Nali, On Tue, Nov 11, 2014 at 12:57 PM, Martin Kosek wrote: > So if the lurking double encoded certificate is in LDAP, and thus Apache DS > shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way > to fix it would be to: > > - Open your Apache DS > - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com > - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry > - Run > # ipa-ldap-updater --upgrade --ldapi --quiet > on your 6.5+ server and the certificate entry should get regenerated (tested > with 7.0). when you write 6.5+ server you mean in the kdc/CA server, right? Just checking :-) Thanks! -- Groeten, natxo From pspacek at redhat.com Tue Nov 11 12:29:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Nov 2014 13:29:02 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> Message-ID: <5462010E.5090407@redhat.com> On 11.11.2014 13:13, Walter van Lille wrote: > SASL encrypted packet length exceeds > maximum allowed limit Martin, do you remember where is the appropriate knob? -- Petr^2 Spacek From roman at naumenko.ca Tue Nov 11 12:52:28 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Tue, 11 Nov 2014 07:52:28 -0500 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <20141111115209.GD19156@redhat.com> References: <5461F1AF.2000708@naumenko.ca> <20141111115209.GD19156@redhat.com> Message-ID: <5462068C.7020105@naumenko.ca> Alexander Bokovoy wrote on 11-11-14 6:52: > On Tue, 11 Nov 2014, Roman Naumenko wrote: >> I'd like to adjust process settings on freeipa server to fit it >> better into virtual instance. >> Is it possible to change settings of java, ns-slapd and apache >> processes somewhere in config files and what those files are? > http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service > ----------------------- > # For example, to pass additional options (for instance, -D > definitions) to the > # httpd binary at startup, you need to create a file named > # "/etc/systemd/system/httpd.service" containing: > # .include /lib/systemd/system/httpd.service > # [Service] > # Environment=OPTIONS=-DMY_DEFINE Isn't it for startup options only? I need to set some of these, they are usually in httpd.conf StartServers 12 MinSpareServers 12 MaxSpareServers 12 MaxClients 12 MaxRequestsPerChild 300 --Roman From abokovoy at redhat.com Tue Nov 11 13:08:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 15:08:31 +0200 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <5462068C.7020105@naumenko.ca> References: <5461F1AF.2000708@naumenko.ca> <20141111115209.GD19156@redhat.com> <5462068C.7020105@naumenko.ca> Message-ID: <20141111130831.GF19156@redhat.com> On Tue, 11 Nov 2014, Roman Naumenko wrote: >Alexander Bokovoy wrote on 11-11-14 6:52: >>On Tue, 11 Nov 2014, Roman Naumenko wrote: >>>I'd like to adjust process settings on freeipa server to fit it >>>better into virtual instance. >>>Is it possible to change settings of java, ns-slapd and apache >>>processes somewhere in config files and what those files are? >>http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service >>----------------------- >># For example, to pass additional options (for instance, -D >>definitions) to the >># httpd binary at startup, you need to create a file named >># "/etc/systemd/system/httpd.service" containing: >># .include /lib/systemd/system/httpd.service >># [Service] >># Environment=OPTIONS=-DMY_DEFINE >Isn't it for startup options only? You've asked about settings for the processes, that's how it is done in systemd environment. Check systemd.resource-control(5) and systemd.exec(5) for details of what can be changed. > >I need to set some of these, they are usually in httpd.conf > > > StartServers 12 > MinSpareServers 12 > MaxSpareServers 12 > MaxClients 12 > MaxRequestsPerChild 300 > This is Apache-specific config and as such should go into /etc/httpd/conf.d/, any file with .conf suffix there is automatically included by httpd during startup thanks to the following in /etc/httpd/conf/httpd.conf: # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf -- / Alexander Bokovoy From mkosek at redhat.com Tue Nov 11 13:13:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 14:13:49 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: References: <20141110161934.GA13814@redhat.com> <5461F98F.3050409@redhat.com> Message-ID: <54620B8D.2060708@redhat.com> On 11/11/2014 01:28 PM, Natxo Asenjo wrote: > hi Nali, > On Tue, Nov 11, 2014 at 12:57 PM, Martin Kosek wrote: > >> So if the lurking double encoded certificate is in LDAP, and thus Apache DS >> shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way >> to fix it would be to: >> >> - Open your Apache DS >> - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com >> - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry >> - Run >> # ipa-ldap-updater --upgrade --ldapi --quiet >> on your 6.5+ server and the certificate entry should get regenerated (tested >> with 7.0). > > when you write 6.5+ server you mean in the kdc/CA server, right? Just > checking :-) > > Thanks! > > -- > Groeten, > natxo > I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that can regenerate CAcert entry without double encoding. Martin From mbasti at redhat.com Tue Nov 11 13:14:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 14:14:17 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> Message-ID: <54620BA9.7070705@redhat.com> Ludiwg (CCed) this seems like old (fixed?) DS bug. On 11/11/14 13:13, Walter van Lille wrote: > I've just cleaned out a ton of slapd_poll timed out messages from the > output and changed the names to protect the innocent, :-) > Here is the output as requested: > > > *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds > maximum allowed limit (length=805634565, limit=2097152). Change the > nsslapd-maxsasliosize attribute in cn=config to increase limit.* > * > * > *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* > *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL > security on connection in CLOSING state* > *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers > from connection* > *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling > operation threads* > *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 > threads to terminate* > *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down > internal subsystems and plugins* > *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* > *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* > *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* > *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 > B2014.219.179 starting up* > *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=sample,dc=example* > *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which > should be added before the CoS Definition.* > *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which > should be added before the CoS Definition.* > *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All > Interfaces port 389 for LDAP requests* > *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 > for LDAPS requests* > *[11/Nov/2014:13:26:36 +0200] - Listening on > /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* > *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* > * > * > * > * > * > * > > > On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote: > > IMHO It's DS bug, can you share DS error log? > pspacek CCed to examine named logs. > > Martin^2 > > > On 11/11/14 12:13, Walter van Lille wrote: >> Hi Martin, thanks for the reply. >> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >> The server doesn't have journalctl installed but I have the >> outputs from the messages and named.run files that I included here: >> >> Messages: >> >> *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) >> resolving 'example.example.com.10.123.123.123/A/IN': >> 2001:500:2f::f#53* >> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >> to adjust "timeout" parameter* >> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >> to adjust "timeout" parameter* >> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >> to adjust "timeout" parameter* >> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >> to adjust "timeout" parameter* >> >> Named.run: >> >> *client 10.123.123.123#42639: transfer of 'example.example/IN': >> AXFR-style IXFR started* >> *client 10.123.123.123#42639: transfer of ''example.example/IN': >> AXFR-style IXFR ended* >> *client 10.123.123.123#46912: transfer of >> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >> *client 10.123.123.123#46912: transfer of >> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> >> I just replaced the IPs and the actual names with something more >> generic. >> >> Regards, >> >> Walter >> >> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti > > wrote: >> >> On 06/11/14 14:58, Walter van Lille wrote: >>> Hi, >>> >>> I need some assistance please. >>> I've taken over an IPA server to manage a few months ago, >>> and it was working fine until recently when it started >>> acting up seemingly off its own accord. >>> When I do an ipactl status it basically gives an output as >>> shown below: >>> >>> >>> *Directory Service: RUNNING >>> * >>> * >>> * >>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>> pause... (To the tune of 7 minutes sometimes)* >>> * >>> * >>> *KDC Service: RUNNING* >>> *KPASSWD Service: RUNNING* >>> *DNS Service: RUNNING* >>> *MEMCACHE Service: RUNNING* >>> *HTTP Service: RUNNING* >>> *CA Service: RUNNING* >>> *ADTRUST Service: RUNNING* >>> *EXTID Service: RUNNING* >>> >>> Running top showed that ns-slapd was munching almost all my >>> resources, but I got that fixed by upping the cache. >>> Unfortunately this did not correct the issue and it still >>> reacts in the same fashion, although the resources have been >>> freed up now. >>> I've noticed that when I run dig on either the local server >>> or a remote machine that the query basically just times out >>> as shown here: >>> >>> *dig freeipa.myexample.sample* >>> * >>> * >>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>> freeipa.myexample.sample* >>> *;; global options: +cmd* >>> *;; connection timed out; no servers could be reached* >>> >>> When the KDC service fails to start, then name lookups seem >>> OK, but authentication fails. otherwise it's dead in the water. >>> >>> This also happens: >>> >>> *sudo ipactl status* >>> *Directory Service: RUNNING* >>> *Unknown error when retrieving list of services from LDAP:* >>> * >>> * >>> My software setup is as follows: >>> >>> *CentOS release 6.5 (Final) >>> * >>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>> * >>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>> * >>> *bind-dyndb-ldap.x86_64* >>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *rpcbind.x86_64 0.2.0-11.el6 >>> @anaconda-CentOS-201311291202.x86_64/6.5* >>> *samba4-winbind.x86_64* >>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>> * >>> * >>> * >>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 >>> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>> * >>> >>> It's not a permanent situation as it sometimes runs 100% for >>> a while, but 80% of the time it is unusable. If anybody can >>> assist me, please be so kind. >>> >>> Regards, >>> >>> Walter >>> >> Hello please which version of bind-dyndb-ldap do you use? >> I had similar issue with bind-dyndb-ldap, but it was >> development version, I'm not sure if this is your case. >> When named was failing, dirserv was really slow. >> >> Can you send journalctl -b -u named log when dig doesn't work?? >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 11 13:16:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 14:16:34 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <5462010E.5090407@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <5462010E.5090407@redhat.com> Message-ID: <54620C32.30105@redhat.com> On 11/11/2014 01:29 PM, Petr Spacek wrote: > On 11.11.2014 13:13, Walter van Lille wrote: >> SASL encrypted packet length exceeds >> maximum allowed limit > > Martin, do you remember where is the appropriate knob? > Do you mean nsslapd-sasl-max-buffer-size setting in cn=config? This is a related ticket https://fedorahosted.org/389/ticket/47457 This is the public, RHEL-7.1 variant of it: https://bugzilla.redhat.com/show_bug.cgi?id=1044193 Martin From lkrispen at redhat.com Tue Nov 11 13:20:18 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 11 Nov 2014 14:20:18 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54620BA9.7070705@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> Message-ID: <54620D12.4050809@redhat.com> On 11/11/2014 02:14 PM, Martin Basti wrote: > Ludiwg (CCed) this seems like old (fixed?) DS bug. hmm, it says limit is 2097152, so it already has the new setting, but the error message says the packet is 800MB* * > > On 11/11/14 13:13, Walter van Lille wrote: >> I've just cleaned out a ton of slapd_poll timed out messages from the >> output and changed the names to protect the innocent, :-) >> Here is the output as requested: >> >> >> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds >> maximum allowed limit (length=805565, limit=2097152). Change the >> nsslapd-maxsasliosize attribute in cn=config to increase limit.* >> * >> * >> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >> security on connection in CLOSING state* >> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers >> from connection* >> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >> operation threads* >> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 >> threads to terminate* >> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >> internal subsystems and plugins* >> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* >> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >> B2014.219.179 starting up* >> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=sample,dc=example* >> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >> which should be added before the CoS Definition.* >> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >> which should be added before the CoS Definition.* >> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests* >> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 >> for LDAPS requests* >> *[11/Nov/2014:13:26:36 +0200] - Listening on >> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >> * >> * >> * >> * >> * >> * >> >> >> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > > wrote: >> >> IMHO It's DS bug, can you share DS error log? >> pspacek CCed to examine named logs. >> >> Martin^2 >> >> >> On 11/11/14 12:13, Walter van Lille wrote: >>> Hi Martin, thanks for the reply. >>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>> The server doesn't have journalctl installed but I have the >>> outputs from the messages and named.run files that I included here: >>> >>> Messages: >>> >>> *Nov 11 12:30:13 freeipa named[1481]: error (network >>> unreachable) resolving >>> 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >>> to adjust "timeout" parameter* >>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >>> to adjust "timeout" parameter* >>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >>> to adjust "timeout" parameter* >>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >>> to adjust "timeout" parameter* >>> >>> Named.run: >>> >>> *client 10.123.123.123#42639: transfer of 'example.example/IN': >>> AXFR-style IXFR started* >>> *client 10.123.123.123#42639: transfer of ''example.example/IN': >>> AXFR-style IXFR ended* >>> *client 10.123.123.123#46912: transfer of >>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>> *client 10.123.123.123#46912: transfer of >>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> >>> I just replaced the IPs and the actual names with something more >>> generic. >>> >>> Regards, >>> >>> Walter >>> >>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >> > wrote: >>> >>> On 06/11/14 14:58, Walter van Lille wrote: >>>> Hi, >>>> >>>> I need some assistance please. >>>> I've taken over an IPA server to manage a few months ago, >>>> and it was working fine until recently when it started >>>> acting up seemingly off its own accord. >>>> When I do an ipactl status it basically gives an output as >>>> shown below: >>>> >>>> >>>> *Directory Service: RUNNING >>>> * >>>> * >>>> * >>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>> pause... (To the tune of 7 minutes sometimes)* >>>> * >>>> * >>>> *KDC Service: RUNNING* >>>> *KPASSWD Service: RUNNING* >>>> *DNS Service: RUNNING* >>>> *MEMCACHE Service: RUNNING* >>>> *HTTP Service: RUNNING* >>>> *CA Service: RUNNING* >>>> *ADTRUST Service: RUNNING* >>>> *EXTID Service: RUNNING* >>>> >>>> Running top showed that ns-slapd was munching almost all my >>>> resources, but I got that fixed by upping the cache. >>>> Unfortunately this did not correct the issue and it still >>>> reacts in the same fashion, although the resources have >>>> been freed up now. >>>> I've noticed that when I run dig on either the local server >>>> or a remote machine that the query basically just times out >>>> as shown here: >>>> >>>> *dig freeipa.myexample.sample* >>>> * >>>> * >>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>> freeipa.myexample.sample* >>>> *;; global options: +cmd* >>>> *;; connection timed out; no servers could be reached* >>>> >>>> When the KDC service fails to start, then name lookups seem >>>> OK, but authentication fails. otherwise it's dead in the water. >>>> >>>> This also happens: >>>> >>>> *sudo ipactl status* >>>> *Directory Service: RUNNING* >>>> *Unknown error when retrieving list of services from LDAP:* >>>> * >>>> * >>>> My software setup is as follows: >>>> >>>> *CentOS release 6.5 (Final) >>>> * >>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>> * >>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>> * >>>> *bind-dyndb-ldap.x86_64* >>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>> *rpcbind.x86_64 0.2.0-11.el6 >>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>> *samba4-winbind.x86_64* >>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>> * >>>> * >>>> * >>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 >>>> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>> * >>>> >>>> It's not a permanent situation as it sometimes runs 100% >>>> for a while, but 80% of the time it is unusable. If anybody >>>> can assist me, please be so kind. >>>> >>>> Regards, >>>> >>>> Walter >>>> >>> Hello please which version of bind-dyndb-ldap do you use? >>> I had similar issue with bind-dyndb-ldap, but it was >>> development version, I'm not sure if this is your case. >>> When named was failing, dirserv was really slow. >>> >>> Can you send journalctl -b -u named log when dig doesn't work?? >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 11 13:33:25 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Nov 2014 14:33:25 +0100 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> <20141110101045.GD5577@hendrix.brq.redhat.com> Message-ID: <20141111133325.GS14216@hendrix.redhat.com> On Mon, Nov 10, 2014 at 09:29:04AM -0800, Michael Lasevich wrote: > I can certainly try, it would need to be compatible with CentOS 6.6 though. > > -M Thank you very much, can you try these packages? Please note they wouldn't fix your problem, but will hopefully shed some more light on what's going on: https://jhrozek.fedorapeople.org/sssd-test-builds/krb5-ccache-debugging/ > > > So according to the logs, the create_ccache() function failed. > Unfortunately, > we don't do very good job at logging the failures there.. > > > >Michael, are you able to run a custom package with extra debugging? It > would help us pinpoint which line actually is failing. > > > >Thanks a lot for providing the logs! From natxo.asenjo at gmail.com Tue Nov 11 13:47:54 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 11 Nov 2014 14:47:54 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: <54620B8D.2060708@redhat.com> References: <20141110161934.GA13814@redhat.com> <5461F98F.3050409@redhat.com> <54620B8D.2060708@redhat.com> Message-ID: hi, On Tue, Nov 11, 2014 at 2:13 PM, Martin Kosek wrote: > I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that > can regenerate CAcert entry without double encoding. ok. So I removed the cacert object and ran ipa-ldap-updater --upgrade --ldapi (it does not know the --quiet switch in this version). And now in he apache directory studio I see the value of the attribue is X509v3: CN=Certificate Authority, O=DOMAIN.TLD So that's fixed. But certmonger on the client still gives me the same errror Could I send you the full log of certmonger privately (1.1M)? Thanks. -- Groeten, natxo From rcritten at redhat.com Tue Nov 11 14:11:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Nov 2014 09:11:39 -0500 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <20141111130831.GF19156@redhat.com> References: <5461F1AF.2000708@naumenko.ca> <20141111115209.GD19156@redhat.com> <5462068C.7020105@naumenko.ca> <20141111130831.GF19156@redhat.com> Message-ID: <5462191B.4080601@redhat.com> Alexander Bokovoy wrote: > On Tue, 11 Nov 2014, Roman Naumenko wrote: >> Alexander Bokovoy wrote on 11-11-14 6:52: >>> On Tue, 11 Nov 2014, Roman Naumenko wrote: >>>> I'd like to adjust process settings on freeipa server to fit it >>>> better into virtual instance. >>>> Is it possible to change settings of java, ns-slapd and apache >>>> processes somewhere in config files and what those files are? >>> http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service >>> ----------------------- >>> # For example, to pass additional options (for instance, -D >>> definitions) to the >>> # httpd binary at startup, you need to create a file named >>> # "/etc/systemd/system/httpd.service" containing: >>> # .include /lib/systemd/system/httpd.service >>> # [Service] >>> # Environment=OPTIONS=-DMY_DEFINE >> Isn't it for startup options only? > You've asked about settings for the processes, that's how it is done in > systemd environment. Check systemd.resource-control(5) and > systemd.exec(5) for details of what can be changed. > >> >> I need to set some of these, they are usually in httpd.conf >> >> >> StartServers 12 >> MinSpareServers 12 >> MaxSpareServers 12 >> MaxClients 12 >> MaxRequestsPerChild 300 >> > This is Apache-specific config and as such should go into > /etc/httpd/conf.d/, any file with .conf suffix there is automatically > included by httpd during startup thanks to the following in > /etc/httpd/conf/httpd.conf: > > # Load config files in the "/etc/httpd/conf.d" directory, if any. > IncludeOptional conf.d/*.conf > It depends on the version of your distro. In recent Fedora a lot of configuration has been split out into separate files. This particular configuration can be found in /etc/httpd/conf.d/prefork.conf. For older releases, on RHEL-6 for example, it is still defined in /etc/httpd/conf/httpd.conf. As for 389-ds, there is no magic-bullet tuning. It is very environment-specific and heavily based on the size of your data. This should help, https://github.com/richm/scripts/wiki/dbmon.sh rob From rcritten at redhat.com Tue Nov 11 14:15:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Nov 2014 09:15:36 -0500 Subject: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support In-Reply-To: References: Message-ID: <54621A08.8010509@redhat.com> Vaclav Adamec wrote: > Hi, > I'm getting "Installed OpenSSH server does not support dynamically > loading authorized user keys. Public key authentication of IPA users > will not be available" during ipa client install on CentOS 6.6 > > Packages openssh-server-6.1p1-5.el6.1.x86_64 and > ipa-client-3.0.0-42.el6.centos.x86_64 > > Manual setup of "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" > in /etc/ssh/sshd_config is ok. > > Any reason for that ? > I'd check the client install log for more details, /var/log/ipaclient-install.log A number of different permutations are tried and the log should have more details on which ones failed (and hopefully why). rob From vaclav.adamec at suchy-zleb.cz Tue Nov 11 14:20:41 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 11 Nov 2014 15:20:41 +0100 Subject: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support In-Reply-To: <54621A08.8010509@redhat.com> References: <54621A08.8010509@redhat.com> Message-ID: Here it is: 2014-11-11T11:45:33Z DEBUG stderr= 2014-11-11T11:45:33Z DEBUG Backing up system configuration file '/etc/ssh/ssh_config' 2014-11-11T11:45:33Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config 2014-11-11T11:45:33Z DEBUG Backing up system configuration file '/etc/ssh/sshd_config' 2014-11-11T11:45:33Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o AuthorizedKeysCommand= 2014-11-11T11:45:33Z DEBUG stdout= 2014-11-11T11:45:33Z DEBUG stderr=command-line line 0: AuthorizedKeysCommand must be an absolute path 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent= 2014-11-11T11:45:33Z DEBUG stdout= 2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad configuration option: PubKeyAgent 2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available. 2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config 2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status 2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid 24698) is running... On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden wrote: > Vaclav Adamec wrote: > > Hi, > > I'm getting "Installed OpenSSH server does not support dynamically > > loading authorized user keys. Public key authentication of IPA users > > will not be available" during ipa client install on CentOS 6.6 > > > > Packages openssh-server-6.1p1-5.el6.1.x86_64 and > > ipa-client-3.0.0-42.el6.centos.x86_64 > > > > Manual setup of "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" > > in /etc/ssh/sshd_config is ok. > > > > Any reason for that ? > > > > I'd check the client install log for more details, > /var/log/ipaclient-install.log > > A number of different permutations are tried and the log should have > more details on which ones failed (and hopefully why). > > rob > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 11 14:44:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Nov 2014 09:44:05 -0500 Subject: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support In-Reply-To: References: <54621A08.8010509@redhat.com> Message-ID: <546220B5.1040702@redhat.com> Vaclav Adamec wrote: > Here it is: > > 2014-11-11T11:45:33Z DEBUG stderr= > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file > '/etc/ssh/ssh_config' > 2014-11-11T11:45:33Z DEBUG Saving Index File to > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file > '/etc/ssh/sshd_config' > 2014-11-11T11:45:33Z DEBUG Saving Index File to > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o > AuthorizedKeysCommand= > 2014-11-11T11:45:33Z DEBUG stdout= > 2014-11-11T11:45:33Z DEBUG stderr=command-line line 0: > AuthorizedKeysCommand must be an absolute path > > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent= > 2014-11-11T11:45:33Z DEBUG stdout= > 2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad > configuration option: PubKeyAgent > > 2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support > dynamically loading authorized user keys. Public key authentication of > IPA users will not be available. > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config > 2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status > 2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid 24698) is running... Seems to be different behavior from sshd. What version do you have installed? On my RHEL-6.x box I see: 2014-11-11T14:40:00Z DEBUG args=sshd -t -f /dev/null -o AuthorizedKeysCommand= 2014-11-11T14:40:00Z DEBUG stdout= 2014-11-11T14:40:00Z DEBUG stderr= 2014-11-11T14:40:00Z INFO Configured /etc/ssh/sshd_config rob > > > On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden > wrote: > > Vaclav Adamec wrote: > > Hi, > > I'm getting "Installed OpenSSH server does not support dynamically > > loading authorized user keys. Public key authentication of IPA users > > will not be available" during ipa client install on CentOS 6.6 > > > > Packages openssh-server-6.1p1-5.el6.1.x86_64 and > > ipa-client-3.0.0-42.el6.centos.x86_64 > > > > Manual setup of "AuthorizedKeysCommand > /usr/bin/sss_ssh_authorizedkeys" > > in /etc/ssh/sshd_config is ok. > > > > Any reason for that ? > > > > I'd check the client install log for more details, > /var/log/ipaclient-install.log > > A number of different permutations are tried and the log should have > more details on which ones failed (and hopefully why). > > rob > > > > > -- > -- May the fox be with you ... > /\ > (~( > ) ) /\_/\ > (_=---_(@ @) > ( \ / > /|/----\|\ V > " " " " > > > > From rmeggins at redhat.com Tue Nov 11 14:58:22 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Nov 2014 07:58:22 -0700 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54620D12.4050809@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> Message-ID: <5462240E.7000401@redhat.com> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: > > On 11/11/2014 02:14 PM, Martin Basti wrote: >> Ludiwg (CCed) this seems like old (fixed?) DS bug. > hmm, it says limit is 2097152, so it already has the new setting, but > the error message says the packet is 800MB* > * *Right. That usually means the server was expecting an encrypted SASL buffer from the client, but instead the client thinks SASL encryption negotiation failed and just sent a plain LDAP buffer. What version of 389-ds-base are you using? rpm -q 389-ds-base https://fedorahosted.org/389/ticket/47416 So, DO NOT increase your sasl io buffer size - it will not fix the problem, and it will leave you open to DoS attacks. * > ** >> >> On 11/11/14 13:13, Walter van Lille wrote: >>> I've just cleaned out a ton of slapd_poll timed out messages from >>> the output and changed the names to protect the innocent, :-) >>> Here is the output as requested: >>> >>> >>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds >>> maximum allowed limit (length=805565, limit=2097152). Change the >>> nsslapd-maxsasliosize attribute in cn=config to increase limit.* >>> * >>> * >>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >>> security on connection in CLOSING state* >>> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO >>> layers from connection* >>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >>> operation threads* >>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 >>> threads to terminate* >>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >>> internal subsystems and plugins* >>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* >>> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>> B2014.219.179 starting up* >>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no >>> entries set up under cn=computers, cn=compat,dc=sample,dc=example* >>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >>> which should be added before the CoS Definition.* >>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >>> which should be added before the CoS Definition.* >>> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests* >>> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 >>> for LDAPS requests* >>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>> * >>> * >>> * >>> * >>> * >>> * >>> >>> >>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >> > wrote: >>> >>> IMHO It's DS bug, can you share DS error log? >>> pspacek CCed to examine named logs. >>> >>> Martin^2 >>> >>> >>> On 11/11/14 12:13, Walter van Lille wrote: >>>> Hi Martin, thanks for the reply. >>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>> The server doesn't have journalctl installed but I have the >>>> outputs from the messages and named.run files that I included here: >>>> >>>> Messages: >>>> >>>> *Nov 11 12:30:13 freeipa named[1481]: error (network >>>> unreachable) resolving >>>> 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >>>> to adjust "timeout" parameter* >>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try >>>> to adjust "timeout" parameter* >>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >>>> to adjust "timeout" parameter* >>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try >>>> to adjust "timeout" parameter* >>>> >>>> Named.run: >>>> >>>> *client 10.123.123.123#42639: transfer of 'example.example/IN': >>>> AXFR-style IXFR started* >>>> *client 10.123.123.123#42639: transfer of >>>> ''example.example/IN': AXFR-style IXFR ended* >>>> *client 10.123.123.123#46912: transfer of >>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>>> *client 10.123.123.123#46912: transfer of >>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> >>>> I just replaced the IPs and the actual names with something >>>> more generic. >>>> >>>> Regards, >>>> >>>> Walter >>>> >>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>> > wrote: >>>> >>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>> Hi, >>>>> >>>>> I need some assistance please. >>>>> I've taken over an IPA server to manage a few months ago, >>>>> and it was working fine until recently when it started >>>>> acting up seemingly off its own accord. >>>>> When I do an ipactl status it basically gives an output as >>>>> shown below: >>>>> >>>>> >>>>> *Directory Service: RUNNING >>>>> * >>>>> * >>>>> * >>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>> pause... (To the tune of 7 minutes sometimes)* >>>>> * >>>>> * >>>>> *KDC Service: RUNNING* >>>>> *KPASSWD Service: RUNNING* >>>>> *DNS Service: RUNNING* >>>>> *MEMCACHE Service: RUNNING* >>>>> *HTTP Service: RUNNING* >>>>> *CA Service: RUNNING* >>>>> *ADTRUST Service: RUNNING* >>>>> *EXTID Service: RUNNING* >>>>> >>>>> Running top showed that ns-slapd was munching almost all >>>>> my resources, but I got that fixed by upping the cache. >>>>> Unfortunately this did not correct the issue and it still >>>>> reacts in the same fashion, although the resources have >>>>> been freed up now. >>>>> I've noticed that when I run dig on either the local >>>>> server or a remote machine that the query basically just >>>>> times out as shown here: >>>>> >>>>> *dig freeipa.myexample.sample* >>>>> * >>>>> * >>>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>> freeipa.myexample.sample* >>>>> *;; global options: +cmd* >>>>> *;; connection timed out; no servers could be reached* >>>>> >>>>> When the KDC service fails to start, then name lookups >>>>> seem OK, but authentication fails. otherwise it's dead in >>>>> the water. >>>>> >>>>> This also happens: >>>>> >>>>> *sudo ipactl status* >>>>> *Directory Service: RUNNING* >>>>> *Unknown error when retrieving list of services from LDAP:* >>>>> * >>>>> * >>>>> My software setup is as follows: >>>>> >>>>> *CentOS release 6.5 (Final) >>>>> * >>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>> * >>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>> * >>>>> *bind-dyndb-ldap.x86_64* >>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>> *samba4-winbind.x86_64* >>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>> * >>>>> * >>>>> * >>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 >>>>> 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>> * >>>>> >>>>> It's not a permanent situation as it sometimes runs 100% >>>>> for a while, but 80% of the time it is unusable. If >>>>> anybody can assist me, please be so kind. >>>>> >>>>> Regards, >>>>> >>>>> Walter >>>>> >>>> Hello please which version of bind-dyndb-ldap do you use? >>>> I had similar issue with bind-dyndb-ldap, but it was >>>> development version, I'm not sure if this is your case. >>>> When named was failing, dirserv was really slow. >>>> >>>> Can you send journalctl -b -u named log when dig doesn't work?? >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 11 15:24:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 16:24:11 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: References: <20141110161934.GA13814@redhat.com> <5461F98F.3050409@redhat.com> <54620B8D.2060708@redhat.com> Message-ID: <54622A1B.4040408@redhat.com> On 11/11/2014 02:47 PM, Natxo Asenjo wrote: > hi, > > On Tue, Nov 11, 2014 at 2:13 PM, Martin Kosek wrote: > >> I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that >> can regenerate CAcert entry without double encoding. > > ok. > > So I removed the cacert object and ran > > ipa-ldap-updater --upgrade --ldapi > > (it does not know the --quiet switch in this version). And now in he > apache directory studio I see the value of the attribue is X509v3: > CN=Certificate Authority, O=DOMAIN.TLD Ah, looks good. > So that's fixed. But certmonger on the client still gives me the same errror > > Could I send you the full log of certmonger privately (1.1M)? Sure. Though Nalin (CCed) would be better candidate as he is knowledgeable about certmonger internals. Martin From natxo.asenjo at gmail.com Tue Nov 11 15:41:42 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 11 Nov 2014 16:41:42 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: <54622A1B.4040408@redhat.com> References: <20141110161934.GA13814@redhat.com> <5461F98F.3050409@redhat.com> <54620B8D.2060708@redhat.com> <54622A1B.4040408@redhat.com> Message-ID: hi, This seems to happen only in 32bits vm's. At least in my limited testing, 2 out 2 32bits hosts running 6.5 after upgrading have this problem. A amd64 host is ok. $ rpm -qa | grep certmonger certmonger-0.75.13-1.el6.x86_64 $ rpm -qa | grep certmonger certmonger-0.75.13-1.el6.i686 -- Groeten, natxo From nalin at redhat.com Tue Nov 11 16:13:12 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 11 Nov 2014 11:13:12 -0500 Subject: [Freeipa-users] certmonger question In-Reply-To: References: <20141110161934.GA13814@redhat.com> Message-ID: <20141111161312.GA28504@redhat.com> On Tue, Nov 11, 2014 at 08:48:18AM +0100, Natxo Asenjo wrote: > 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority" > valid for 31473668s. > 2014-11-11 08:34:33 [11677] Running result is 1481416576. > 2014-11-11 08:34:33 [11677] Final result is 1481416576. Okay, that's weird. The result being tallied here is the earliest of the not-valid-after times for the CA's certificate, but on my development box, those numbers are coming back scaled up by a factor of a million. That suggests that the logic that determines how long to wait before trying to fetch new data is somehow arriving at a much lower value than it should, which would explain why it immediately polls for a new local signer certificate. Since you mention that this seems to be specific to 32-bit boxes, I think I need to switch to that one to try to sort out what's happening here, since I'm on a 64-bit box. [snip] > # CACert, ipa, etc, domain.tld > dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld > cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF > EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK > MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT > WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV > FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF > BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1 > STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ > 2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW > 5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF > XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv > azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd > zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU > 0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN > Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC > QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb > WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE > 9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM > 5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu > d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY > 0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2 > NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV > qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ== > > # search result > search: 4 > result: 0 Success Yup. If you trim the whitespace and run that through 'base64 -d', you'll see base64-encoded data. If you run _that_ through 'base64 -d', you'll get the certificate, which confirms that it was double-encoded, as I think Martin noted. [snip] > So there is something wrong but how come I only see this in this > client after upgrading it to centos 6.6? Not specifically. Caching the root certificate (for the "IPA" and "local" signers, anyway), is new functionality that was added for other users. HTH, Nalin From vaclav.adamec at suchy-zleb.cz Tue Nov 11 16:10:51 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Tue, 11 Nov 2014 17:10:51 +0100 Subject: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support In-Reply-To: <546220B5.1040702@redhat.com> References: <54621A08.8010509@redhat.com> <546220B5.1040702@redhat.com> Message-ID: openssh-6.1p1-5.el6.1.x86_64 libssh2-1.4.2-1.el6.x86_64 openssh-clients-6.1p1-5.el6.1.x86_64 openssh-server-6.1p1-5.el6.1.x86_64 it's up2date centos66 with 6.1 openssh, but same issue is for 6.7. I'll check rpmspec if there is no issue with dynamically loading authorized user keys, I'm not aware about any disabled functionality. Also I'll try fresh CentOS 6.6 with default 5.3 openssh. Vasek On Tue, Nov 11, 2014 at 3:44 PM, Rob Crittenden wrote: > Vaclav Adamec wrote: > > Here it is: > > > > 2014-11-11T11:45:33Z DEBUG stderr= > > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file > > '/etc/ssh/ssh_config' > > 2014-11-11T11:45:33Z DEBUG Saving Index File to > > '/var/lib/ipa-client/sysrestore/sysrestore.index' > > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config > > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file > > '/etc/ssh/sshd_config' > > 2014-11-11T11:45:33Z DEBUG Saving Index File to > > '/var/lib/ipa-client/sysrestore/sysrestore.index' > > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o > > AuthorizedKeysCommand= > > 2014-11-11T11:45:33Z DEBUG stdout= > > 2014-11-11T11:45:33Z DEBUG stderr=command-line line 0: > > AuthorizedKeysCommand must be an absolute path > > > > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent= > > 2014-11-11T11:45:33Z DEBUG stdout= > > 2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad > > configuration option: PubKeyAgent > > > > 2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support > > dynamically loading authorized user keys. Public key authentication of > > IPA users will not be available. > > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config > > 2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status > > 2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid 24698) is > running... > > Seems to be different behavior from sshd. What version do you have > installed? > > On my RHEL-6.x box I see: > > 2014-11-11T14:40:00Z DEBUG args=sshd -t -f /dev/null -o > AuthorizedKeysCommand= > 2014-11-11T14:40:00Z DEBUG stdout= > 2014-11-11T14:40:00Z DEBUG stderr= > 2014-11-11T14:40:00Z INFO Configured /etc/ssh/sshd_config > > rob > > > > > > > On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden > > wrote: > > > > Vaclav Adamec wrote: > > > Hi, > > > I'm getting "Installed OpenSSH server does not support dynamically > > > loading authorized user keys. Public key authentication of IPA > users > > > will not be available" during ipa client install on CentOS 6.6 > > > > > > Packages openssh-server-6.1p1-5.el6.1.x86_64 and > > > ipa-client-3.0.0-42.el6.centos.x86_64 > > > > > > Manual setup of "AuthorizedKeysCommand > > /usr/bin/sss_ssh_authorizedkeys" > > > in /etc/ssh/sshd_config is ok. > > > > > > Any reason for that ? > > > > > > > I'd check the client install log for more details, > > /var/log/ipaclient-install.log > > > > A number of different permutations are tried and the log should have > > more details on which ones failed (and hopefully why). > > > > rob > > > > > > > > > > -- > > -- May the fox be with you ... > > /\ > > (~( > > ) ) /\_/\ > > (_=---_(@ @) > > ( \ / > > /|/----\|\ V > > " " " " > > > > > > > > > > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Nov 11 17:37:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 18:37:13 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <5462240E.7000401@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> Message-ID: <54624949.6030200@redhat.com> On 11/11/14 15:58, Rich Megginson wrote: > On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >> >> On 11/11/2014 02:14 PM, Martin Basti wrote: >>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >> hmm, it says limit is 2097152, so it already has the new setting, but >> the error message says the packet is 800MB* >> * > > *Right. That usually means the server was expecting an encrypted SASL > buffer from the client, but instead the client thinks SASL encryption > negotiation failed and just sent a plain LDAP buffer. What version of > 389-ds-base are you using? rpm -q 389-ds-base > > https://fedorahosted.org/389/ticket/47416 > > So, DO NOT increase your sasl io buffer size - it will not fix the > problem, and it will leave you open to DoS attacks. > * He is using CentOS release 6.5 (Final) 389-ds-base.x86_64 1.2.11.15-34.el6_5 > * > * >> ** >>> >>> On 11/11/14 13:13, Walter van Lille wrote: >>>> I've just cleaned out a ton of slapd_poll timed out messages from >>>> the output and changed the names to protect the innocent, :-) >>>> Here is the output as requested: >>>> >>>> >>>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length >>>> exceeds maximum allowed limit (length=805565, limit=2097152). >>>> Change the nsslapd-maxsasliosize attribute in cn=config to increase >>>> limit.* >>>> * >>>> * >>>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >>>> security on connection in CLOSING state* >>>> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO >>>> layers from connection* >>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >>>> operation threads* >>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for >>>> 30 threads to terminate* >>>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >>>> internal subsystems and plugins* >>>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* >>>> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >>>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>>> B2014.219.179 starting up* >>>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no >>>> entries set up under cn=computers, cn=compat,dc=sample,dc=example* >>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >>>> which should be added before the CoS Definition.* >>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, >>>> which should be added before the CoS Definition.* >>>> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests* >>>> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port >>>> 636 for LDAPS requests* >>>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>>> * >>>> * >>>> * >>>> * >>>> * >>>> * >>>> >>>> >>>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >>> > wrote: >>>> >>>> IMHO It's DS bug, can you share DS error log? >>>> pspacek CCed to examine named logs. >>>> >>>> Martin^2 >>>> >>>> >>>> On 11/11/14 12:13, Walter van Lille wrote: >>>>> Hi Martin, thanks for the reply. >>>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>>> The server doesn't have journalctl installed but I have the >>>>> outputs from the messages and named.run files that I included >>>>> here: >>>>> >>>>> Messages: >>>>> >>>>> *Nov 11 12:30:13 freeipa named[1481]: error (network >>>>> unreachable) resolving >>>>> 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. >>>>> Try to adjust "timeout" parameter* >>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. >>>>> Try to adjust "timeout" parameter* >>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. >>>>> Try to adjust "timeout" parameter* >>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. >>>>> Try to adjust "timeout" parameter* >>>>> >>>>> Named.run: >>>>> >>>>> *client 10.123.123.123#42639: transfer of >>>>> 'example.example/IN': AXFR-style IXFR started* >>>>> *client 10.123.123.123#42639: transfer of >>>>> ''example.example/IN': AXFR-style IXFR ended* >>>>> *client 10.123.123.123#46912: transfer of >>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>>>> *client 10.123.123.123#46912: transfer of >>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>> >>>>> I just replaced the IPs and the actual names with something >>>>> more generic. >>>>> >>>>> Regards, >>>>> >>>>> Walter >>>>> >>>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>>>> > wrote: >>>>> >>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>>> Hi, >>>>>> >>>>>> I need some assistance please. >>>>>> I've taken over an IPA server to manage a few months ago, >>>>>> and it was working fine until recently when it started >>>>>> acting up seemingly off its own accord. >>>>>> When I do an ipactl status it basically gives an output >>>>>> as shown below: >>>>>> >>>>>> >>>>>> *Directory Service: RUNNING >>>>>> * >>>>>> * >>>>>> * >>>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>>> pause... (To the tune of 7 minutes sometimes)* >>>>>> * >>>>>> * >>>>>> *KDC Service: RUNNING* >>>>>> *KPASSWD Service: RUNNING* >>>>>> *DNS Service: RUNNING* >>>>>> *MEMCACHE Service: RUNNING* >>>>>> *HTTP Service: RUNNING* >>>>>> *CA Service: RUNNING* >>>>>> *ADTRUST Service: RUNNING* >>>>>> *EXTID Service: RUNNING* >>>>>> >>>>>> Running top showed that ns-slapd was munching almost all >>>>>> my resources, but I got that fixed by upping the cache. >>>>>> Unfortunately this did not correct the issue and it still >>>>>> reacts in the same fashion, although the resources have >>>>>> been freed up now. >>>>>> I've noticed that when I run dig on either the local >>>>>> server or a remote machine that the query basically just >>>>>> times out as shown here: >>>>>> >>>>>> *dig freeipa.myexample.sample* >>>>>> * >>>>>> * >>>>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>>> freeipa.myexample.sample* >>>>>> *;; global options: +cmd* >>>>>> *;; connection timed out; no servers could be reached* >>>>>> >>>>>> When the KDC service fails to start, then name lookups >>>>>> seem OK, but authentication fails. otherwise it's dead in >>>>>> the water. >>>>>> >>>>>> This also happens: >>>>>> >>>>>> *sudo ipactl status* >>>>>> *Directory Service: RUNNING* >>>>>> *Unknown error when retrieving list of services from LDAP:* >>>>>> * >>>>>> * >>>>>> My software setup is as follows: >>>>>> >>>>>> *CentOS release 6.5 (Final) >>>>>> * >>>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>>> * >>>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>>> * >>>>>> *bind-dyndb-ldap.x86_64* >>>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>>> *samba4-winbind.x86_64* >>>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>>> * >>>>>> * >>>>>> * >>>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 >>>>>> 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>>> * >>>>>> >>>>>> It's not a permanent situation as it sometimes runs 100% >>>>>> for a while, but 80% of the time it is unusable. If >>>>>> anybody can assist me, please be so kind. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Walter >>>>>> >>>>> Hello please which version of bind-dyndb-ldap do you use? >>>>> I had similar issue with bind-dyndb-ldap, but it was >>>>> development version, I'm not sure if this is your case. >>>>> When named was failing, dirserv was really slow. >>>>> >>>>> Can you send journalctl -b -u named log when dig doesn't >>>>> work?? >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> >>> >>> -- >>> Martin Basti >> >> >> > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 11 18:03:06 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Nov 2014 11:03:06 -0700 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54624949.6030200@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> Message-ID: <54624F5A.8020304@redhat.com> On 11/11/2014 10:37 AM, Martin Basti wrote: > On 11/11/14 15:58, Rich Megginson wrote: >> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >>> >>> On 11/11/2014 02:14 PM, Martin Basti wrote: >>>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >>> hmm, it says limit is 2097152, so it already has the new setting, >>> but the error message says the packet is 800MB* >>> * >> >> *Right. That usually means the server was expecting an encrypted >> SASL buffer from the client, but instead the client thinks SASL >> encryption negotiation failed and just sent a plain LDAP buffer. >> What version of 389-ds-base are you using? rpm -q 389-ds-base >> >> https://fedorahosted.org/389/ticket/47416 >> >> So, DO NOT increase your sasl io buffer size - it will not fix the >> problem, and it will leave you open to DoS attacks. >> * > > He is using > > CentOS release 6.5 (Final) > 389-ds-base.x86_64 1.2.11.15-34.el6_5 Ignore the "SASL encrypted packet length exceeds maximum allowed limit" error. All it means is the client has some error and is canceling the connection. The bugzilla associated with *47416 is targeted for RHEL 7.1. The problem is that we were never able to figure out what error the client was getting that caused the client to stop establishing the *SASL encryption, and the original customer who reported the problem dropped the case - everything just started working, no further errors. Note that 47416 doesn't really fix the problem or address the root cause - the root cause is some error on the client side that causes it to stop doing encrypted SASL I/O and send an LDAP unbind request. Let's get back to the actual problem - what is the actual problem? The ldap server is hanging or unresponsive? If so, then see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. Let's get some dirsrv stack traces during the period of time when it appears to be unresponsive. > >> * >> * >>> ** >>>> >>>> On 11/11/14 13:13, Walter van Lille wrote: >>>>> I've just cleaned out a ton of slapd_poll timed out messages from >>>>> the output and changed the names to protect the innocent, :-) >>>>> Here is the output as requested: >>>>> >>>>> >>>>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length >>>>> exceeds maximum allowed limit (length=805565, limit=2097152). >>>>> Change the nsslapd-maxsasliosize attribute in cn=config to >>>>> increase limit.* >>>>> * >>>>> * >>>>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>>>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >>>>> security on connection in CLOSING state* >>>>> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO >>>>> layers from connection* >>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >>>>> operation threads* >>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for >>>>> 30 threads to terminate* >>>>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >>>>> internal subsystems and plugins* >>>>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to >>>>> stop* >>>>> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >>>>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>>>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>>>> B2014.219.179 starting up* >>>>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no >>>>> entries set up under cn=computers, cn=compat,dc=sample,dc=example* >>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS >>>>> Templates found, which should be added before the CoS Definition.* >>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS >>>>> Templates found, which should be added before the CoS Definition.* >>>>> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >>>>> Interfaces port 389 for LDAP requests* >>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port >>>>> 636 for LDAPS requests* >>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>>>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>>>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>>>> * >>>>> * >>>>> * >>>>> * >>>>> * >>>>> * >>>>> >>>>> >>>>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >>>> > wrote: >>>>> >>>>> IMHO It's DS bug, can you share DS error log? >>>>> pspacek CCed to examine named logs. >>>>> >>>>> Martin^2 >>>>> >>>>> >>>>> On 11/11/14 12:13, Walter van Lille wrote: >>>>>> Hi Martin, thanks for the reply. >>>>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>>>> The server doesn't have journalctl installed but I have the >>>>>> outputs from the messages and named.run files that I included >>>>>> here: >>>>>> >>>>>> Messages: >>>>>> >>>>>> *Nov 11 12:30:13 freeipa named[1481]: error (network >>>>>> unreachable) resolving >>>>>> 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. >>>>>> Try to adjust "timeout" parameter* >>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. >>>>>> Try to adjust "timeout" parameter* >>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. >>>>>> Try to adjust "timeout" parameter* >>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. >>>>>> Try to adjust "timeout" parameter* >>>>>> >>>>>> Named.run: >>>>>> >>>>>> *client 10.123.123.123#42639: transfer of >>>>>> 'example.example/IN': AXFR-style IXFR started* >>>>>> *client 10.123.123.123#42639: transfer of >>>>>> ''example.example/IN': AXFR-style IXFR ended* >>>>>> *client 10.123.123.123#46912: transfer of >>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>>>>> *client 10.123.123.123#46912: transfer of >>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>> >>>>>> I just replaced the IPs and the actual names with something >>>>>> more generic. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Walter >>>>>> >>>>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>>>>> > wrote: >>>>>> >>>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I need some assistance please. >>>>>>> I've taken over an IPA server to manage a few months >>>>>>> ago, and it was working fine until recently when it >>>>>>> started acting up seemingly off its own accord. >>>>>>> When I do an ipactl status it basically gives an output >>>>>>> as shown below: >>>>>>> >>>>>>> >>>>>>> *Directory Service: RUNNING >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>>>> pause... (To the tune of 7 minutes sometimes)* >>>>>>> * >>>>>>> * >>>>>>> *KDC Service: RUNNING* >>>>>>> *KPASSWD Service: RUNNING* >>>>>>> *DNS Service: RUNNING* >>>>>>> *MEMCACHE Service: RUNNING* >>>>>>> *HTTP Service: RUNNING* >>>>>>> *CA Service: RUNNING* >>>>>>> *ADTRUST Service: RUNNING* >>>>>>> *EXTID Service: RUNNING* >>>>>>> >>>>>>> Running top showed that ns-slapd was munching almost all >>>>>>> my resources, but I got that fixed by upping the cache. >>>>>>> Unfortunately this did not correct the issue and it >>>>>>> still reacts in the same fashion, although the resources >>>>>>> have been freed up now. >>>>>>> I've noticed that when I run dig on either the local >>>>>>> server or a remote machine that the query basically just >>>>>>> times out as shown here: >>>>>>> >>>>>>> *dig freeipa.myexample.sample* >>>>>>> * >>>>>>> * >>>>>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>>>> freeipa.myexample.sample* >>>>>>> *;; global options: +cmd* >>>>>>> *;; connection timed out; no servers could be reached* >>>>>>> >>>>>>> When the KDC service fails to start, then name lookups >>>>>>> seem OK, but authentication fails. otherwise it's dead >>>>>>> in the water. >>>>>>> >>>>>>> This also happens: >>>>>>> >>>>>>> *sudo ipactl status* >>>>>>> *Directory Service: RUNNING* >>>>>>> *Unknown error when retrieving list of services from LDAP:* >>>>>>> * >>>>>>> * >>>>>>> My software setup is as follows: >>>>>>> >>>>>>> *CentOS release 6.5 (Final) >>>>>>> * >>>>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>>>> * >>>>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>>>> * >>>>>>> *bind-dyndb-ldap.x86_64* >>>>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>>>> *samba4-winbind.x86_64* >>>>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 >>>>>>> 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>>>> * >>>>>>> >>>>>>> It's not a permanent situation as it sometimes runs 100% >>>>>>> for a while, but 80% of the time it is unusable. If >>>>>>> anybody can assist me, please be so kind. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Walter >>>>>>> >>>>>> Hello please which version of bind-dyndb-ldap do you use? >>>>>> I had similar issue with bind-dyndb-ldap, but it was >>>>>> development version, I'm not sure if this is your case. >>>>>> When named was failing, dirserv was really slow. >>>>>> >>>>>> Can you send journalctl -b -u named log when dig doesn't >>>>>> work?? >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> >>>> >>>> -- >>>> Martin Basti >>> >>> >>> >> >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Nov 11 18:14:03 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 11 Nov 2014 13:14:03 -0500 Subject: [Freeipa-users] certmonger question In-Reply-To: <20141111161312.GA28504@redhat.com> References: <20141110161934.GA13814@redhat.com> <20141111161312.GA28504@redhat.com> Message-ID: <20141111181403.GB28504@redhat.com> On Tue, Nov 11, 2014 at 11:13:12AM -0500, Nalin Dahyabhai wrote: > Since you mention that this seems to be specific to 32-bit boxes, I > think I need to switch to that one to try to sort out what's happening > here, since I'm on a 64-bit box. Okay, found it, and as 64-bit cleanliness sometimes is, it's a one-line change. The nightlies should have it starting with anything claiming to be 0.76.7 or later. If you can open this in bugzilla, it'll probably look less weird to parts of management than if I did it. Thanks, Nalin From janellenicole80 at gmail.com Tue Nov 11 18:30:33 2014 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 11 Nov 2014 10:30:33 -0800 Subject: [Freeipa-users] strange DS errors trying to tune... Message-ID: <546255C9.7040807@gmail.com> Hi all.. I continue to come up with strange and unusual problems. Here is a new one - use the dbmon.sh script and trying to tune the dbcache... This is on a replica BTW First -- THIS WORKS: INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 dbmon.sh and I see all the info I need, BUT - now I want to tune it and get: (HOW CAN THIS BE?!?!) # ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config > changetype: modify > replace: nsslapd-cachememsize > nsslapd-cachememsize: 8589934592 > EOF ldap_bind: Invalid credentials (49) Thanks ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 11 18:39:22 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Nov 2014 11:39:22 -0700 Subject: [Freeipa-users] strange DS errors trying to tune... In-Reply-To: <546255C9.7040807@gmail.com> References: <546255C9.7040807@gmail.com> Message-ID: <546257DA.2030804@redhat.com> On 11/11/2014 11:30 AM, Janelle wrote: > Hi all.. > > I continue to come up with strange and unusual problems. Here is a new > one - use the dbmon.sh script and trying to tune the dbcache... > > This is on a replica BTW > > First -- THIS WORKS: > > INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 dbmon.sh > > and I see all the info I need, BUT - now I want to tune it and get: > (HOW CAN THIS BE?!?!) > > # ldapmodify -x -D "cn=directory manager" -w asecret < > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config > > changetype: modify > > replace: nsslapd-cachememsize > > nsslapd-cachememsize: 8589934592 > > EOF > ldap_bind: Invalid credentials (49) Is asecret the literal password? If not, does it contain spaces or other shell metacharacters that need to be quoted or escaped? > > Thanks > ~J > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Nov 11 19:19:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Nov 2014 14:19:02 -0500 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> Message-ID: <20141111141902.53c904f6@willson.usersys.redhat.com> On Tue, 11 Nov 2014 04:17:37 +0000 Les Stott wrote: > > -----Original Message----- > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > Sent: Tuesday, 11 November 2014 1:59 PM > > To: Les Stott > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] how to overcome same serial number in > > cert issue on different master servers? > > > > On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > > > > -----Original Message----- > > > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > > > Sent: Tuesday, 11 November 2014 12:51 PM > > > > To: Les Stott > > > > Cc: freeipa-users at redhat.com > > > > Subject: Re: [Freeipa-users] how to overcome same serial number > > > > in cert issue on different master servers? > > > > > > > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > > > > Hi, > > > > > > > > > > I have a standard rhel6 deployment for FreeIPA in two > > > > > environments. > > > > > > > > > > One environment is in our Production Data Center, The Other > > > > > in our DR > > > > Data Center. > > > > > > > > > > Both environments are setup with the same domain > > > > > (mydomain.com) for > > > > FreeIPA. This is to support dr/failover etc. > > > > > > > > > > In each environment, there is a master. In Prod its > > > > > serverA.mydomain.com, > > > > In DR its serverB.mydomain.com. > > > > > > > > > > The master in each environment gets a generated certificate by > > > > > IPA. This > > > > certificate shows a Serial Number of "0A" > > > > > > > > > > My problem is that because the certificates have the same > > > > > Organization, > > > > OU and Serial Number, I can only browse to one of them (using > > > > Firefox). > > > > > > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and > > > > > accept the > > > > certificate it works fine. > > > > > If I then try to browse to > > > > > https://serverB.mydomain.com/ipa/ui/ it comes > > > > up with the following error: > > > > > > > > > > "Your certificate contains the same serial number as another > > > > > certificate > > > > issued by the certificate authority. Please get a new > > > > certificate containing a unique serial number. (Error code: > > sec_error_reused_issuer_and_serial)" > > > > > > > > > > If I remove the stored browser certificate for serverA, then > > > > > browse to > > > > serverB, and accept the certificate, it works, but then the > > > > "same serial number" error pops up for browsing serverA. > > > > > > > > > > Note: both environments were built separately and are not > > > > > linked in > > > > anyway (no replication between prod/dr). > > > > > > > > > > Is there a way to generate unique serial numbers for the > > > > > masters? > > > > > > > > > > Thanks in advance, > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > Hi Les, > > > > > > > > Ideally, you should prevent this situation by using different > > > > common names > > > > (CN) for your CAs and server certifications across the different > > > > environments. If this is not possible, you can configure the > > > > Dogtag CA to use random serial numbers: > > > > > > > > > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > > > > se_Random_Certificate_Serial_Numbers > > > > > > > > This does not guarantee that you will not get serial number > > > > collisions, but reduces the likelihood. > > > > > > > > > > Thanks for the quick reply. > > > > > > In this case the common name is different between both > > > environments. In prod the master was serverA, in DR the master > > > was serverB. It just happened that way. So having a different > > > CommonName doesn't help. > > > > > Do the CA certificates bear the same commonName? This is probably > > what Firefox uses to determine if there are serial number > > collisions. > > > > It appears so. > > The certificate for the CA on the master serverA shows: > > Issued To > Common Name (CN) serverA.mydomain.com > Organization (O) mydomain.com > Organizational Unit (OU) > Serial Number 0A > Issued By: > Common Name (CN) Certificate Authority > Organization (O) mydomain.com > Organizational Unit (OU) > > The certificate for the CA on the master serverB shows: > > Issued To > Common Name (CN) serverB.mydomain.com > Organization (O) mydomain.com > Organizational Unit (OU) > Serial Number 0A > Issued By: > Common Name (CN) Certificate Authority > Organization (O) mydomain.com > Organizational Unit (OU) > > > Shouldn't the Common Name of the CA be different? Or is it the same > in order to make CA replication easier? > > Is there a way to re-issue certificates for the masters so they get > unique serial numbers (without making the systems blow up)? It is strongly advised not to use the same domain/realm name for 2 different IPA installations, there are a ton of weird and extremely hard to debug errors that will come your way if you do so. *especially* if you have clients that access both environments. A better scheme would be to use mydfomain.com from prod and dr.mydomain.com for the other. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Nov 11 19:27:49 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Nov 2014 14:27:49 -0500 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <20141111141902.53c904f6@willson.usersys.redhat.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> <20141111141902.53c904f6@willson.usersys.redhat.com> Message-ID: <20141111142749.557710c6@willson.usersys.redhat.com> On Tue, 11 Nov 2014 14:19:02 -0500 Simo Sorce wrote: > On Tue, 11 Nov 2014 04:17:37 +0000 > Les Stott wrote: > > > > -----Original Message----- > > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > > Sent: Tuesday, 11 November 2014 1:59 PM > > > To: Les Stott > > > Cc: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] how to overcome same serial number in > > > cert issue on different master servers? > > > > > > On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > > > > > -----Original Message----- > > > > > From: Fraser Tweedale [mailto:ftweedal at redhat.com] > > > > > Sent: Tuesday, 11 November 2014 12:51 PM > > > > > To: Les Stott > > > > > Cc: freeipa-users at redhat.com > > > > > Subject: Re: [Freeipa-users] how to overcome same serial > > > > > number in cert issue on different master servers? > > > > > > > > > > On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > > > > > > Hi, > > > > > > > > > > > > I have a standard rhel6 deployment for FreeIPA in two > > > > > > environments. > > > > > > > > > > > > One environment is in our Production Data Center, The Other > > > > > > in our DR > > > > > Data Center. > > > > > > > > > > > > Both environments are setup with the same domain > > > > > > (mydomain.com) for > > > > > FreeIPA. This is to support dr/failover etc. > > > > > > > > > > > > In each environment, there is a master. In Prod its > > > > > > serverA.mydomain.com, > > > > > In DR its serverB.mydomain.com. > > > > > > > > > > > > The master in each environment gets a generated certificate > > > > > > by IPA. This > > > > > certificate shows a Serial Number of "0A" > > > > > > > > > > > > My problem is that because the certificates have the same > > > > > > Organization, > > > > > OU and Serial Number, I can only browse to one of them (using > > > > > Firefox). > > > > > > > > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and > > > > > > accept the > > > > > certificate it works fine. > > > > > > If I then try to browse to > > > > > > https://serverB.mydomain.com/ipa/ui/ it comes > > > > > up with the following error: > > > > > > > > > > > > "Your certificate contains the same serial number as another > > > > > > certificate > > > > > issued by the certificate authority. Please get a new > > > > > certificate containing a unique serial number. (Error code: > > > sec_error_reused_issuer_and_serial)" > > > > > > > > > > > > If I remove the stored browser certificate for serverA, then > > > > > > browse to > > > > > serverB, and accept the certificate, it works, but then the > > > > > "same serial number" error pops up for browsing serverA. > > > > > > > > > > > > Note: both environments were built separately and are not > > > > > > linked in > > > > > anyway (no replication between prod/dr). > > > > > > > > > > > > Is there a way to generate unique serial numbers for the > > > > > > masters? > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > Hi Les, > > > > > > > > > > Ideally, you should prevent this situation by using different > > > > > common names > > > > > (CN) for your CAs and server certifications across the > > > > > different environments. If this is not possible, you can > > > > > configure the Dogtag CA to use random serial numbers: > > > > > > > > > > > > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > > > > > se_Random_Certificate_Serial_Numbers > > > > > > > > > > This does not guarantee that you will not get serial number > > > > > collisions, but reduces the likelihood. > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > In this case the common name is different between both > > > > environments. In prod the master was serverA, in DR the master > > > > was serverB. It just happened that way. So having a different > > > > CommonName doesn't help. > > > > > > > Do the CA certificates bear the same commonName? This is probably > > > what Firefox uses to determine if there are serial number > > > collisions. > > > > > > > It appears so. > > > > The certificate for the CA on the master serverA shows: > > > > Issued To > > Common Name (CN) serverA.mydomain.com > > Organization (O) mydomain.com > > Organizational Unit (OU) > > Serial Number 0A > > Issued By: > > Common Name (CN) Certificate Authority > > Organization (O) mydomain.com > > Organizational Unit (OU) > > > > The certificate for the CA on the master serverB shows: > > > > Issued To > > Common Name (CN) serverB.mydomain.com > > Organization (O) mydomain.com > > Organizational Unit (OU) > > Serial Number 0A > > Issued By: > > Common Name (CN) Certificate Authority > > Organization (O) mydomain.com > > Organizational Unit (OU) > > > > > > Shouldn't the Common Name of the CA be different? Or is it the same > > in order to make CA replication easier? > > > > Is there a way to re-issue certificates for the masters so they get > > unique serial numbers (without making the systems blow up)? > > It is strongly advised not to use the same domain/realm name for 2 > different IPA installations, there are a ton of weird and extremely > hard to debug errors that will come your way if you do so. > *especially* if you have clients that access both environments. > > A better scheme would be to use mydfomain.com from prod and > dr.mydomain.com for the other. Oh, I just realized that in your first email yuou said you used the same name for failover/disaster recovery. This will *not* work as well as you think. All certificates and all Kerberos keys will fail to work if you create 2 domains that just happen to have the same name, but really have different CA keys and Kerberos keys. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Nov 11 19:32:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Nov 2014 14:32:34 -0500 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <20141111051607.GK3743@dhcp-40-8.bne.redhat.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> <20141111051607.GK3743@dhcp-40-8.bne.redhat.com> Message-ID: <54626452.5090607@redhat.com> Fraser Tweedale wrote: > On Tue, Nov 11, 2014 at 04:17:37AM +0000, Les Stott wrote: >>> -----Original Message----- >>> From: Fraser Tweedale [mailto:ftweedal at redhat.com] >>> Sent: Tuesday, 11 November 2014 1:59 PM >>> To: Les Stott >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] how to overcome same serial number in cert >>> issue on different master servers? >>> >>> On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: >>>>> -----Original Message----- >>>>> From: Fraser Tweedale [mailto:ftweedal at redhat.com] >>>>> Sent: Tuesday, 11 November 2014 12:51 PM >>>>> To: Les Stott >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] how to overcome same serial number in >>>>> cert issue on different master servers? >>>>> >>>>> On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: >>>>>> Hi, >>>>>> >>>>>> I have a standard rhel6 deployment for FreeIPA in two environments. >>>>>> >>>>>> One environment is in our Production Data Center, The Other in our >>>>>> DR >>>>> Data Center. >>>>>> >>>>>> Both environments are setup with the same domain (mydomain.com) >>>>>> for >>>>> FreeIPA. This is to support dr/failover etc. >>>>>> >>>>>> In each environment, there is a master. In Prod its >>>>>> serverA.mydomain.com, >>>>> In DR its serverB.mydomain.com. >>>>>> >>>>>> The master in each environment gets a generated certificate by >>>>>> IPA. This >>>>> certificate shows a Serial Number of "0A" >>>>>> >>>>>> My problem is that because the certificates have the same >>>>>> Organization, >>>>> OU and Serial Number, I can only browse to one of them (using Firefox). >>>>>> >>>>>> If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the >>>>> certificate it works fine. >>>>>> If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it >>>>>> comes >>>>> up with the following error: >>>>>> >>>>>> "Your certificate contains the same serial number as another >>>>>> certificate >>>>> issued by the certificate authority. Please get a new certificate >>>>> containing a unique serial number. (Error code: >>> sec_error_reused_issuer_and_serial)" >>>>>> >>>>>> If I remove the stored browser certificate for serverA, then >>>>>> browse to >>>>> serverB, and accept the certificate, it works, but then the "same >>>>> serial number" error pops up for browsing serverA. >>>>>> >>>>>> Note: both environments were built separately and are not linked >>>>>> in >>>>> anyway (no replication between prod/dr). >>>>>> >>>>>> Is there a way to generate unique serial numbers for the masters? >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> Les >>>>>> >>>>>> >>>>>> >>>>> Hi Les, >>>>> >>>>> Ideally, you should prevent this situation by using different common >>>>> names >>>>> (CN) for your CAs and server certifications across the different >>>>> environments. If this is not possible, you can configure the Dogtag >>>>> CA to use random serial numbers: >>>>> >>>>> >>> http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U >>>>> se_Random_Certificate_Serial_Numbers >>>>> >>>>> This does not guarantee that you will not get serial number >>>>> collisions, but reduces the likelihood. >>>>> >>>> >>>> Thanks for the quick reply. >>>> >>>> In this case the common name is different between both environments. >>>> In prod the master was serverA, in DR the master was serverB. It just >>>> happened that way. So having a different CommonName doesn't help. >>>> >>> Do the CA certificates bear the same commonName? This is probably what >>> Firefox uses to determine if there are serial number collisions. >>> >> >> It appears so. >> >> The certificate for the CA on the master serverA shows: >> >> Issued To >> Common Name (CN) serverA.mydomain.com >> Organization (O) mydomain.com >> Organizational Unit (OU) >> Serial Number 0A >> Issued By: >> Common Name (CN) Certificate Authority >> Organization (O) mydomain.com >> Organizational Unit (OU) >> >> The certificate for the CA on the master serverB shows: >> >> Issued To >> Common Name (CN) serverB.mydomain.com >> Organization (O) mydomain.com >> Organizational Unit (OU) >> Serial Number 0A >> Issued By: >> Common Name (CN) Certificate Authority >> Organization (O) mydomain.com >> Organizational Unit (OU) >> >> >> Shouldn't the Common Name of the CA be different? Or is it the same in order to make CA replication easier? >> > Both environments were probably set up with the same CN for the CA > (perhaps a default name). I don't think this has anything to do > with replication. > >> Is there a way to re-issue certificates for the masters so they get unique serial numbers (without making the systems blow up)? >> > You can manually renew a certificate using Certmonger: > > http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate > > You should enable random serial numbers before doing this. The problem here isn't the server certs, it's the CA certs. He has two CA's with the same subjects and serial numbers claiming to be the same thing. Honza added the ipa-cacert-manage command which can re-issue the CA certificate, but I forget if this is only available in 4.1 or also 4.0. You probably only need to do this on one of the masters. As Simo pointed out though, having two environments with the same realm should be avoided if possible. rob From janellenicole80 at gmail.com Tue Nov 11 19:33:49 2014 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 11 Nov 2014 11:33:49 -0800 Subject: [Freeipa-users] strange DS errors trying to tune... In-Reply-To: <546257DA.2030804@redhat.com> References: <546255C9.7040807@gmail.com> <546257DA.2030804@redhat.com> Message-ID: <5462649D.4030102@gmail.com> In this case it is the exact password and it worked in the first line but not in the second. Now to make things even more strange -- I have 8 replicas -- and 3 of them show this problem, the others do not -- WOW.. My brain is going to explode today. :-) ~J > Rich Megginson > November 11, 2014 at 10:39 AM > On 11/11/2014 11:30 AM, Janelle wrote: >> Hi all.. >> >> I continue to come up with strange and unusual problems. Here is a >> new one - use the dbmon.sh script and trying to tune the dbcache... >> >> This is on a replica BTW >> >> First -- THIS WORKS: >> >> INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 >> dbmon.sh >> >> and I see all the info I need, BUT - now I want to tune it and get: >> (HOW CAN THIS BE?!?!) >> >> # ldapmodify -x -D "cn=directory manager" -w asecret <> > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config >> > changetype: modify >> > replace: nsslapd-cachememsize >> > nsslapd-cachememsize: 8589934592 >> > EOF >> ldap_bind: Invalid credentials (49) > > Is asecret the literal password? If not, does it contain spaces or > other shell metacharacters that need to be quoted or escaped? > >> >> Thanks >> ~J >> >> >> > > Janelle > November 11, 2014 at 10:30 AM > Hi all.. > > I continue to come up with strange and unusual problems. Here is a new > one - use the dbmon.sh script and trying to tune the dbcache... > > This is on a replica BTW > > First -- THIS WORKS: > > INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 dbmon.sh > > and I see all the info I need, BUT - now I want to tune it and get: > (HOW CAN THIS BE?!?!) > > # ldapmodify -x -D "cn=directory manager" -w asecret < > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config > > changetype: modify > > replace: nsslapd-cachememsize > > nsslapd-cachememsize: 8589934592 > > EOF > ldap_bind: Invalid credentials (49) > > Thanks > ~J > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From rmeggins at redhat.com Tue Nov 11 19:37:25 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Nov 2014 12:37:25 -0700 Subject: [Freeipa-users] strange DS errors trying to tune... In-Reply-To: <5462649D.4030102@gmail.com> References: <546255C9.7040807@gmail.com> <546257DA.2030804@redhat.com> <5462649D.4030102@gmail.com> Message-ID: <54626575.7030107@redhat.com> On 11/11/2014 12:33 PM, Janelle wrote: > In this case it is the exact password and it worked in the first line > but not in the second. > > Now to make things even more strange -- I have 8 replicas -- and 3 of > them show this problem, the others do not -- WOW.. > > My brain is going to explode today. :-) Yeah, sorry, I have no idea. Please let us know if you figure it out. > > ~J > >> Rich Megginson >> November 11, 2014 at 10:39 AM >> On 11/11/2014 11:30 AM, Janelle wrote: >>> Hi all.. >>> >>> I continue to come up with strange and unusual problems. Here is a >>> new one - use the dbmon.sh script and trying to tune the dbcache... >>> >>> This is on a replica BTW >>> >>> First -- THIS WORKS: >>> >>> INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 >>> dbmon.sh >>> >>> and I see all the info I need, BUT - now I want to tune it and get: >>> (HOW CAN THIS BE?!?!) >>> >>> # ldapmodify -x -D "cn=directory manager" -w asecret <>> > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config >>> > changetype: modify >>> > replace: nsslapd-cachememsize >>> > nsslapd-cachememsize: 8589934592 >>> > EOF >>> ldap_bind: Invalid credentials (49) >> >> Is asecret the literal password? If not, does it contain spaces or >> other shell metacharacters that need to be quoted or escaped? >> >>> >>> Thanks >>> ~J >>> >>> >>> >> >> Janelle >> November 11, 2014 at 10:30 AM >> Hi all.. >> >> I continue to come up with strange and unusual problems. Here is a >> new one - use the dbmon.sh script and trying to tune the dbcache... >> >> This is on a replica BTW >> >> First -- THIS WORKS: >> >> INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 dbmon.sh >> >> and I see all the info I need, BUT - now I want to tune it and get: >> (HOW CAN THIS BE?!?!) >> >> # ldapmodify -x -D "cn=directory manager" -w asecret <> > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config >> > changetype: modify >> > replace: nsslapd-cachememsize >> > nsslapd-cachememsize: 8589934592 >> > EOF >> ldap_bind: Invalid credentials (49) >> >> Thanks >> ~J >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From abokovoy at redhat.com Tue Nov 11 20:00:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 22:00:35 +0200 Subject: [Freeipa-users] strange DS errors trying to tune... In-Reply-To: <5462649D.4030102@gmail.com> References: <546255C9.7040807@gmail.com> <546257DA.2030804@redhat.com> <5462649D.4030102@gmail.com> Message-ID: <20141111200035.GA3493@redhat.com> On Tue, 11 Nov 2014, Janelle wrote: >In this case it is the exact password and it worked in the first line >but not in the second. > >Now to make things even more strange -- I have 8 replicas -- and 3 of >them show this problem, the others do not -- WOW.. cn=config subtree is not replicated in FreeIPA, thus if you have different passwords for Directory Manager (they are stored in cn=config), this must be a problem local to a replica, not a replication issue. Perhaps some script or a person changed the directory manager's password? For the record, the password is stored in nsslapd-rootpw attribute of cn=config: dn: cn=config nsslapd-rootdn: cn=Directory Manager nsslapd-rootpw: {SSHA}some-hash-value You can check the content of /etc/dirsrv/slapd-INSTANCE/dse.ldif directly. Do not change the file while directory server is running as your changes will be overridden. -- / Alexander Bokovoy From mlasevich at gmail.com Tue Nov 11 22:49:10 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Tue, 11 Nov 2014 14:49:10 -0800 Subject: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6 In-Reply-To: <20141111133325.GS14216@hendrix.redhat.com> References: <5A645F9F0CA5764F8D1F624A2C5429EA0E4C1660@SC-EXCHANGE.speedcast.com> <20141105090507.GZ14368@hendrix.brq.redhat.com> <5A645F9F0CA5764F8D1F624A2C5429EA0E4C3EE1@SC-EXCHANGE.speedcast.com> <20141107091831.GM14368@hendrix.brq.redhat.com> <20141110101045.GD5577@hendrix.brq.redhat.com> <20141111133325.GS14216@hendrix.redhat.com> Message-ID: <54629266.9060508@gmail.com> Sending you logs directly. Thanks. -M On 11/11/14, 5:33 AM, Jakub Hrozek wrote: > On Mon, Nov 10, 2014 at 09:29:04AM -0800, Michael Lasevich wrote: >> I can certainly try, it would need to be compatible with CentOS 6.6 though. >> >> -M > Thank you very much, can you try these packages? > > Please note they wouldn't fix your problem, but will hopefully shed some > more light on what's going on: > https://jhrozek.fedorapeople.org/sssd-test-builds/krb5-ccache-debugging/ > >>> So according to the logs, the create_ccache() function failed. >> Unfortunately, >> we don't do very good job at logging the failures there.. >>> Michael, are you able to run a custom package with extra debugging? It >> would help us pinpoint which line actually is failing. >>> Thanks a lot for providing the logs! From rolf_16_nufable at yahoo.com Wed Nov 12 03:09:45 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 11 Nov 2014 19:09:45 -0800 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <5461EEBB.2020402@redhat.com> References: <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461DD40.6060507@redhat.com> <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> <20141111101106.GM14216@hendrix.redhat.com> <5461EEBB.2020402@redhat.com> Message-ID: <1415761785.86862.YahooMailNeo@web161603.mail.bf1.yahoo.com> I have another question, well I've achieved the state where I can't log in to my admin account in the server side, it happens because I'm changing the time of the server machine. but the time is really wrong. and I disabled NTP and the server has no access to the internet. these are my network configurations. peerdns = no ipaddr = 192.168.1.1 netmask = 255.255.255.0 dns1 = 192.168.1.1 onboot = yes as you can see I've made the server also the dns1, (is this correct though ? i really don't know ) feel free to correct my network config And another problem is that I need to sync my freeipa server time to the right time zone? if thats the case then I do need internet connection for my Freeipa server , so that it could access ntp servers right? ( or am I wrong? ) still this is a great breakthrough for my work Now what to do? ps. Martin attached is the krb5kdc.log after I changed the time of the server. Httpd error log didnt changed at all after I tried to access the web UI and tried to log in.. TIA On Tuesday, November 11, 2014 7:10 PM, Petr Vobornik wrote: On 11.11.2014 11:11, Jakub Hrozek wrote: > On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: >> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) >> >> well I'm having this error in the client side when using the command su - ( user ) >> >> su - user at example.com >> >> su : user at example.com does not exist. > > Are you sure ipa-client-install did run successfully on that machine? > > Can you unenroll and enroll the client back so that we start from an > sssd.conf that is created by the tooling? > > As Martin said, you don't need those sudo-related config options with > recent SSSD releases, they wouldn't work in the sudo section anyway. Does: $ id user at example.com return you the user info? if not and ipa-client-install was run successfully before, check nsswitch.conf if it has sssd configured (sss next to various providers). if not run: $ authconfig --enablesssd --update if it doesn't help, try to run: $ authconfig --disablesssd --update $ authconfig --enablesssd --update if it helps, please tell me. I'm curious if you suffer from one issue I experienced. > >> >> >> >> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: >> >> >> >> It is still really hard to give advise as I do not know what's actually wrong. >> So are you trying to set up a sudo on your client or are you trying to log in >> with your client browser to FreeIPA server? These are 2 orthogonal actions. >> >> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I >> cannot help you without described procedure you are trying to do, logs and >> exact error messages. >> >> Martin >> >> >> On 11/11/2014 09:32 AM, Rolf Nufable wrote: >>> never mind the problem on the server side, somehow it got fixed , I really don't know how though >>> >>> so in the client side , It is successful when installing free ipa client and the >> server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) >>> >>> So I really don't know why Can't I connect to the ipa server. >>> >>> Iptables works fine. >>> /etc/resolv.conf is file as well >>> >>> sssd/sssd.conf ( added these lines ) >>> [sudo] >>> sudo_provider = ldap >>> ldap_uri = ldap://myipaserver.example.com >>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>> ldap_sasl_mech = GSSAPI >>> ldap_sasl_authid = host/myipaserver.example.com >>> ldap_sasl_realm = EXAMPLE.COM >>> krb_server = myipaserver.example.com >>> >>> >>> and /etc/nsswitch.conf >>> (added this line ) >>> >>> sudoers : files sss ldap >>> >>> is there something missing ? >>> >>> >>> >>> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: >>> >>> >>> >>> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either >> you are on the server or client side, or at least thats what I remember. >>> >>> Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs >>> >>> >>> >>> >>> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: >>> >>> >>> >>> On 11/11/2014 08:07 AM, Rolf Nufable wrote: >>>> well I dont know how or what command to use to display the logs, could you teach me how? >>> >>> There should be HOWTO articles on how to do that. Jakub may have better >>> sources, but I see for >> example: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html >>> >>>> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only >>> >>> network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. >>> >>>> while on the client side, even >>> though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. >>> >>> FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, >>> if SSO login fails. Does at least this part work? Because if not, there is some >>> error on the server side. It would be interesting to check if there are no >>> errors on the server in following logs: >>> - /var/log/httpd/error_log >>> - /var/log/krb5kdc.log >>> >>> >>> >>>> >>>> TIA >>>> >>>> >>>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >>>> >>>> >>>> >>>> On 11/11/2014 06:37 AM, Rolf Nufable >> wrote: >>>>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >>>> >>>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >>>> deploy, on the >>> contrary, it should be much cooler than 3.3. >>>> >>>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>>>> >>>>> >>>>> >>>>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>>>> >>>>> sudo_provider = ldap >>>>> ldap_uri = ldap://myipaserver.example.com >>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>> ldap_sasl_mech = >>> GSSAPI >>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>> ldap_sasl_realm = EXAMPLE.COM >>>>> krb_server = myipaserver.example.com >>>> >>>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >>>> provider. Actually, FreeIPA 4.0+ clients do that for you. >>>> >>>> More info here: >>>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>> https://fedorahosted.org/freeipa/ticket/3358 >>>> >>>>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >>>> >>>> Are you sure that network.negotiate-auth.trusted-uris in about:config >>>> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >>>> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >>>> is the setting of network.negotiate-auth.trusted-uris? >>>> >>>> In any case, it is still hard to >>> advise as I still did not see any related >>>> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >>>> >>>> Thanks, >>>> Martin >>>> >>>> >>>>> >>>>> >>>>> TIA >>>>> >>>>> >>>>> >>>>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>>>> >>>>>> On 11/10/2014 02:05 AM, Rolf >>>>> Nufable wrote: >>>>>>> Hello >>>>>>> >>>>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>>>> >>>>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it >>> in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question >> is how can I solve this problem?? I've been at it for 3 weeks now .. >>>>>> >>>>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>>>> CCing Lukas and Jakub to advise. >>>>> >>>>> Sorry, I skipped this thread b/c the subject didn't look like it was >>>>> SSSD-related. >>>>> >>>>> I think we need to examine SSSD logs... >>>>> -- Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: krb5kdclog.png Type: image/png Size: 302207 bytes Desc: not available URL: From Less at imagine-sw.com Wed Nov 12 04:15:34 2014 From: Less at imagine-sw.com (Les Stott) Date: Wed, 12 Nov 2014 04:15:34 +0000 Subject: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? In-Reply-To: <54626452.5090607@redhat.com> References: <4ED173A868981548967B4FCA27072226280233A5@AACMBXP04.exchserver.com> <20141111015059.GI3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA2707222628023438@AACMBXP04.exchserver.com> <20141111025915.GJ3743@dhcp-40-8.bne.redhat.com> <4ED173A868981548967B4FCA270722262802363D@AACMBXP04.exchserver.com> <20141111051607.GK3743@dhcp-40-8.bne.redhat.com> <54626452.5090607@redhat.com> Message-ID: <4ED173A868981548967B4FCA270722262802513D@AACMBXP04.exchserver.com> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, 12 November 2014 6:33 AM > To: Fraser Tweedale; Les Stott > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] how to overcome same serial number in cert > issue on different master servers? > > Fraser Tweedale wrote: > > On Tue, Nov 11, 2014 at 04:17:37AM +0000, Les Stott wrote: > >>> -----Original Message----- > >>> From: Fraser Tweedale [mailto:ftweedal at redhat.com] > >>> Sent: Tuesday, 11 November 2014 1:59 PM > >>> To: Les Stott > >>> Cc: freeipa-users at redhat.com > >>> Subject: Re: [Freeipa-users] how to overcome same serial number in > >>> cert issue on different master servers? > >>> > >>> On Tue, Nov 11, 2014 at 02:11:55AM +0000, Les Stott wrote: > >>>>> -----Original Message----- > >>>>> From: Fraser Tweedale [mailto:ftweedal at redhat.com] > >>>>> Sent: Tuesday, 11 November 2014 12:51 PM > >>>>> To: Les Stott > >>>>> Cc: freeipa-users at redhat.com > >>>>> Subject: Re: [Freeipa-users] how to overcome same serial number in > >>>>> cert issue on different master servers? > >>>>> > >>>>> On Tue, Nov 11, 2014 at 01:40:50AM +0000, Les Stott wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I have a standard rhel6 deployment for FreeIPA in two > environments. > >>>>>> > >>>>>> One environment is in our Production Data Center, The Other in > >>>>>> our DR > >>>>> Data Center. > >>>>>> > >>>>>> Both environments are setup with the same domain > (mydomain.com) > >>>>>> for > >>>>> FreeIPA. This is to support dr/failover etc. > >>>>>> > >>>>>> In each environment, there is a master. In Prod its > >>>>>> serverA.mydomain.com, > >>>>> In DR its serverB.mydomain.com. > >>>>>> > >>>>>> The master in each environment gets a generated certificate by > >>>>>> IPA. This > >>>>> certificate shows a Serial Number of "0A" > >>>>>> > >>>>>> My problem is that because the certificates have the same > >>>>>> Organization, > >>>>> OU and Serial Number, I can only browse to one of them (using > Firefox). > >>>>>> > >>>>>> If I browse to https://serverA.mydomain.com/ipa/ui/ and accept > >>>>>> the > >>>>> certificate it works fine. > >>>>>> If I then try to browse to https://serverB.mydomain.com/ipa/ui/ > >>>>>> it comes > >>>>> up with the following error: > >>>>>> > >>>>>> "Your certificate contains the same serial number as another > >>>>>> certificate > >>>>> issued by the certificate authority. Please get a new certificate > >>>>> containing a unique serial number. (Error code: > >>> sec_error_reused_issuer_and_serial)" > >>>>>> > >>>>>> If I remove the stored browser certificate for serverA, then > >>>>>> browse to > >>>>> serverB, and accept the certificate, it works, but then the "same > >>>>> serial number" error pops up for browsing serverA. > >>>>>> > >>>>>> Note: both environments were built separately and are not linked > >>>>>> in > >>>>> anyway (no replication between prod/dr). > >>>>>> > >>>>>> Is there a way to generate unique serial numbers for the masters? > >>>>>> > >>>>>> Thanks in advance, > >>>>>> > >>>>>> Les > >>>>>> > >>>>>> > >>>>>> > >>>>> Hi Les, > >>>>> > >>>>> Ideally, you should prevent this situation by using different > >>>>> common names > >>>>> (CN) for your CAs and server certifications across the different > >>>>> environments. If this is not possible, you can configure the > >>>>> Dogtag CA to use random serial numbers: > >>>>> > >>>>> > >>> > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U > >>>>> se_Random_Certificate_Serial_Numbers > >>>>> > >>>>> This does not guarantee that you will not get serial number > >>>>> collisions, but reduces the likelihood. > >>>>> > >>>> > >>>> Thanks for the quick reply. > >>>> > >>>> In this case the common name is different between both > environments. > >>>> In prod the master was serverA, in DR the master was serverB. It > >>>> just happened that way. So having a different CommonName doesn't > help. > >>>> > >>> Do the CA certificates bear the same commonName? This is probably > >>> what Firefox uses to determine if there are serial number collisions. > >>> > >> > >> It appears so. > >> > >> The certificate for the CA on the master serverA shows: > >> > >> Issued To > >> Common Name (CN) serverA.mydomain.com Organization (O) > mydomain.com > >> Organizational Unit (OU) Serial Number 0A > >> Issued By: > >> Common Name (CN) Certificate Authority Organization (O) > mydomain.com > >> Organizational Unit (OU) > >> > >> The certificate for the CA on the master serverB shows: > >> > >> Issued To > >> Common Name (CN) serverB.mydomain.com Organization (O) > mydomain.com > >> Organizational Unit (OU) Serial Number 0A > >> Issued By: > >> Common Name (CN) Certificate Authority Organization (O) > mydomain.com > >> Organizational Unit (OU) > >> > >> > >> Shouldn't the Common Name of the CA be different? Or is it the same in > order to make CA replication easier? > >> > > Both environments were probably set up with the same CN for the CA > > (perhaps a default name). I don't think this has anything to do with > > replication. > > > >> Is there a way to re-issue certificates for the masters so they get unique > serial numbers (without making the systems blow up)? > >> > > You can manually renew a certificate using Certmonger: > > > > > > http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate > > > > You should enable random serial numbers before doing this. > > The problem here isn't the server certs, it's the CA certs. He has two CA's > with the same subjects and serial numbers claiming to be the same thing. > > Honza added the ipa-cacert-manage command which can re-issue the CA > certificate, but I forget if this is only available in 4.1 or also 4.0. > > You probably only need to do this on one of the masters. > > As Simo pointed out though, having two environments with the same realm > should be avoided if possible. > > rob While both environments are identical in terms of domain names, they are separate in config and use. Hosts in prod only reference prod ipa servers. Hosts in DR only reference dr ipa servers. The problem only arises with the cert because I use the same browser to browse each ipa server. It's the browser which cannot handle the same serial number/CA common name. I don't believe this has any impact on ipa client hosts as they don't cross between prod and dr. So, workarounds.... 1. in prod, use https:///ipa/ui/ In dr, use https:///ipa/ui/ Or 2. use Firefox to browse one master, Use chrome to browse the other. I had a quick look at randomizing dogtag serial numbers and manually renewing a certificate, tried it on a spare test server but couldn't get it to work (It is rhel6, ipa 3.0.0.37 and dogtag 9). I can live with that for now. In the not too distant future the next task will be a rhel7/ipa 4 upgrade. Looks like this issue will go away or be easier to manage in later versions. I appreciate everyone's input on this. Thanks, Les From mkosek at redhat.com Wed Nov 12 07:11:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Nov 2014 08:11:50 +0100 Subject: [Freeipa-users] strange error deleting replica? In-Reply-To: <54623B07.3060504@gmail.com> References: <5460FCB7.3060309@gmail.com> <5461ECA7.6000203@redhat.com> <54623B07.3060504@gmail.com> Message-ID: <54630836.1040705@redhat.com> Adding freeipa-users list back. Would the ipa.strace log below then tell which name resolution fail? On 11/11/2014 05:36 PM, Janelle wrote: > On all the systems, besides being in DNS (external server) they are all in > /etc/hosts, so not sure why that would error. > But indeed they all resolve in DNS as well. > > Hmm.. > ~J >> Martin Kosek >> November 11, 2014 at 3:01 AM >> >> This is usually DNS resolution error, though the command should not crash this >> way. >> >> Does follow resolution work? >> >> $ host `hostname` >> $ host kermit.xyzzy.com >> >> Alternatively, if you are not sure which DNS resolution fails, we could look at >> strace output: >> >> $ strace -o ipa.strace ipa-replica-manage del kermit.xyzzy.com --force >> >> That would create a log caled ipa.strace with all system calls of >> ipa-replica-manage del command and we would see which DNS resolution failed. >> >> Martin > From mkosek at redhat.com Wed Nov 12 07:34:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Nov 2014 08:34:39 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <1415761785.86862.YahooMailNeo@web161603.mail.bf1.yahoo.com> References: <20141110124137.GF5577@hendrix.brq.redhat.com> <1415683462.91389.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415684237.64571.YahooMailNeo@web161601.mail.bf1.yahoo.com> <5461B30E.8080108@redhat.com> <1415689670.55339.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461BA96.1070805@redhat.com> <1415691942.64298.YahooMailNeo@web161606.mail.bf1.yahoo.com> <1415694773.60991.YahooMailNeo@web161602.mail.bf1.yahoo.com> <5461DD40.6060507@redhat.com> <1415700477.89997.YahooMailNeo@web161603.mail.bf1.yahoo.com> <20141111101106.GM14216@hendrix.redhat.com> <5461EEBB.2020402@redhat.com> <1415761785.86862.YahooMailNeo@web161603.mail.bf1.yahoo.com> Message-ID: <54630D8F.2020002@redhat.com> On 11/12/2014 04:09 AM, Rolf Nufable wrote: > I have another question, well I've achieved the state where I can't log in to my admin account in the server side, it happens because I'm changing the time of the server machine. > > but the time is really wrong. and I disabled NTP and the server has no access to the internet. > > these are my network configurations. > > peerdns = no > ipaddr = 192.168.1.1 > netmask = 255.255.255.0 > dns1 = 192.168.1.1 > onboot = yes > > as you can see I've made the server also the dns1, (is this correct though ? i really don't know ) > > feel free to correct my network config > > And another problem is that I need to sync my freeipa server time to the right time zone? if thats the case then I do need internet connection for my Freeipa server , so that it could access ntp servers right? ( or am I wrong? ) Yes, internet connection helps. Theoretically you could just set up the time manually on your FreeIPA server and then let your clients synchronize their time with it as NTP is running there, but that may be cumbersome. > > still this is a great breakthrough for my work > > Now what to do? FreeIPA server and the KDC do not care about the time zone, it works with UTC time anyway, AFAIK. You just simply need to have the time synchronized on all your servers and clients or Kerberos protocol will not work. > ps. Martin attached is the krb5kdc.log after I changed the time of the server. Httpd error log didnt changed at all after I tried to access the web UI and tried to log in.. I saw no error there... > > > TIA > > > > On Tuesday, November 11, 2014 7:10 PM, Petr Vobornik wrote: > > > > On 11.11.2014 11:11, Jakub Hrozek wrote: >> On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: >>> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) >>> >>> well I'm having this error in the client side when using the command su - ( user ) >>> >>> su - user at example.com >>> >>> su : user at example.com does not exist. >> >> Are you sure ipa-client-install did run successfully on that machine? >> >> Can you unenroll and enroll the client back so that we start from an >> sssd.conf that is created by the tooling? >> >> As Martin said, you don't need those sudo-related config options with >> recent SSSD releases, they wouldn't work in the sudo section anyway. > > Does: > > $ id user at example.com > > return you the user info? > > if not and ipa-client-install was run successfully before, check > nsswitch.conf if it has sssd configured (sss next to various providers). > > if not run: > $ authconfig --enablesssd --update > > if it doesn't help, try to run: > $ authconfig --disablesssd --update > $ authconfig --enablesssd --update > > if it helps, please tell me. I'm curious if you suffer from one issue I > experienced. > > > >> >>> >>> >>> >>> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: >>> >>> >>> >>> It is still really hard to give advise as I do not know what's actually wrong. >>> So are you trying to set up a sudo on your client or are you trying to log in >>> with your client browser to FreeIPA server? These are 2 orthogonal actions. >>> >>> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I >>> cannot help you without described procedure you are trying to do, logs and >>> exact error messages. >>> >>> Martin >>> >>> >>> On 11/11/2014 09:32 AM, Rolf Nufable wrote: >>>> never mind the problem on the server side, somehow it got fixed , I really don't know how though >>>> >>>> so in the client side , It is successful when installing free ipa client and the >>> server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) >>>> >>>> So I really don't know why Can't I connect to the ipa server. >>>> >>>> Iptables works fine. >>>> /etc/resolv.conf is file as well >>>> >>>> sssd/sssd.conf ( added these lines ) >>>> [sudo] >>>> sudo_provider = ldap >>>> ldap_uri = ldap://myipaserver.example.com >>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>> ldap_sasl_mech = GSSAPI >>>> ldap_sasl_authid = host/myipaserver.example.com >>>> ldap_sasl_realm = EXAMPLE.COM >>>> krb_server = myipaserver.example.com >>>> >>>> >>>> and /etc/nsswitch.conf >>>> (added this line ) >>>> >>>> sudoers : files sss ldap >>>> >>>> is there something missing ? >>>> >>>> >>>> >>>> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: >>>> >>>> >>>> >>>> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either >>> you are on the server or client side, or at least thats what I remember. >>>> >>>> Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs >>>> >>>> >>>> >>>> >>>> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: >>>> >>>> >>>> >>>> On 11/11/2014 08:07 AM, Rolf Nufable wrote: >>>>> well I dont know how or what command to use to display the logs, could you teach me how? >>>> >>>> There should be HOWTO articles on how to do that. Jakub may have better >>>> sources, but I see for >>> example: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html >>>> >>>>> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only >>>> >>>> network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. >>>> >>>>> while on the client side, even >>>> though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. >>>> >>>> FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, >>>> if SSO login fails. Does at least this part work? Because if not, there is some >>>> error on the server side. It would be interesting to check if there are no >>>> errors on the server in following logs: >>>> - /var/log/httpd/error_log >>>> - /var/log/krb5kdc.log >>>> >>>> >>>> >>>>> >>>>> TIA >>>>> >>>>> >>>>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >>>>> >>>>> >>>>> >>>>> On 11/11/2014 06:37 AM, Rolf Nufable >>> wrote: >>>>>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >>>>> >>>>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >>>>> deploy, on the >>>> contrary, it should be much cooler than 3.3. >>>>> >>>>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>>>>> >>>>>> >>>>>> >>>>>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>>>>> >>>>>> sudo_provider = ldap >>>>>> ldap_uri = ldap://myipaserver.example.com >>>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>>> ldap_sasl_mech = >>>> GSSAPI >>>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>>> ldap_sasl_realm = EXAMPLE.COM >>>>>> krb_server = myipaserver.example.com >>>>> >>>>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >>>>> provider. Actually, FreeIPA 4.0+ clients do that for you. >>>>> >>>>> More info here: >>>>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>>> https://fedorahosted.org/freeipa/ticket/3358 >>>>> >>>>>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >>>>> >>>>> Are you sure that network.negotiate-auth.trusted-uris in about:config >>>>> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >>>>> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >>>>> is the setting of network.negotiate-auth.trusted-uris? >>>>> >>>>> In any case, it is still hard to >>>> advise as I still did not see any related >>>>> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> >>>>>> >>>>>> >>>>>> TIA >>>>>> >>>>>> >>>>>> >>>>>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>>>>> >>>>>>> On 11/10/2014 02:05 AM, Rolf >>>>>> Nufable wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>>>>> >>>>>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it >>>> in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question >>> is how can I solve this problem?? I've been at it for 3 weeks now .. >>>>>>> >>>>>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>>>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>>>>> CCing Lukas and Jakub to advise. >>>>>> >>>>>> Sorry, I skipped this thread b/c the subject didn't look like it was >>>>>> SSSD-related. >>>>>> >>>>>> I think we need to examine SSSD logs... >>>>>> > > From natxo.asenjo at gmail.com Wed Nov 12 09:12:21 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 12 Nov 2014 10:12:21 +0100 Subject: [Freeipa-users] certmonger question In-Reply-To: <20141111181403.GB28504@redhat.com> References: <20141110161934.GA13814@redhat.com> <20141111161312.GA28504@redhat.com> <20141111181403.GB28504@redhat.com> Message-ID: hi, On Tue, Nov 11, 2014 at 7:14 PM, Nalin Dahyabhai wrote: > On Tue, Nov 11, 2014 at 11:13:12AM -0500, Nalin Dahyabhai wrote: >> Since you mention that this seems to be specific to 32-bit boxes, I >> think I need to switch to that one to try to sort out what's happening >> here, since I'm on a 64-bit box. > > Okay, found it, and as 64-bit cleanliness sometimes is, it's a one-line > change. The nightlies should have it starting with anything claiming to > be 0.76.7 or later. If you can open this in bugzilla, it'll probably > look less weird to parts of management than if I did it. :-) Awesome. I filed it: https://bugzilla.redhat.com/show_bug.cgi?id=1163023 (very summarily, if you require me to fill in more information I will be happy to do it; I added a link to this thread on the mailing list archive). In the meantime until the fix hits the repositories I have excluded certmonger from yum update and in an upgraded centos 6.6 32bit host certmonger keeps working. Thanks for your support. -- Groeten, natxo From walter.van.lille at gmail.com Wed Nov 12 12:42:44 2014 From: walter.van.lille at gmail.com (Walter van Lille) Date: Wed, 12 Nov 2014 14:42:44 +0200 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54624F5A.8020304@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> Message-ID: Thanks again for the assistance guys. I have saved two files and included it here. Hope it tells you more than it does me. Regards, Wallter On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson wrote: > On 11/11/2014 10:37 AM, Martin Basti wrote: > > On 11/11/14 15:58, Rich Megginson wrote: > > On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: > > > On 11/11/2014 02:14 PM, Martin Basti wrote: > > Ludiwg (CCed) this seems like old (fixed?) DS bug. > > hmm, it says limit is 2097152, so it already has the new setting, but the > error message says the packet is 800MB > > > > > > > > *Right. That usually means the server was expecting an encrypted SASL > buffer from the client, but instead the client thinks SASL encryption > negotiation failed and just sent a plain LDAP buffer. What version of > 389-ds-base are you using? rpm -q 389-ds-base > https://fedorahosted.org/389/ticket/47416 > So, DO NOT increase your sasl > io buffer size - it will not fix the problem, and it will leave you open to > DoS attacks. * > > > He is using > > CentOS release 6.5 (Final) > 389-ds-base.x86_64 1.2.11.15-34.el6_5 > > > > Ignore the "SASL encrypted packet length exceeds maximum allowed limit" > error. All it means is the client has some error and is canceling the > connection. > > The bugzilla associated with *47416 > is targeted for RHEL 7.1. The > problem is that we were never able to figure out what error the client was > getting that caused the client to stop establishing the *SASL encryption, > and the original customer who reported the problem dropped the case - > everything just started working, no further errors. Note that 47416 > doesn't really fix the problem or address the root cause - the root cause > is some error on the client side that causes it to stop doing encrypted > SASL I/O and send an LDAP unbind request. > > Let's get back to the actual problem - what is the actual problem? The > ldap server is hanging or unresponsive? If so, then see > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. Let's > get some dirsrv stack traces during the period of time when it appears to > be unresponsive. > > > > > > On 11/11/14 13:13, Walter van Lille wrote: > > I've just cleaned out a ton of slapd_poll timed out messages from the > output and changed the names to protect the innocent, :-) > Here is the output as requested: > > > *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds > maximum allowed limit (length=805565, limit=2097152). Change the > nsslapd-maxsasliosize attribute in cn=config to increase limit.* > > *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* > *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL security > on connection in CLOSING state* > *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers from > connection* > *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling > operation threads* > *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 > threads to terminate* > *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down > internal subsystems and plugins* > *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* > *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* > *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* > *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 > B2014.219.179 starting up* > *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries > set up under cn=computers, cn=compat,dc=sample,dc=example* > *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which > should be added before the CoS Definition.* > *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which > should be added before the CoS Definition.* > *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All > Interfaces port 389 for LDAP requests* > *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for > LDAPS requests* > *[11/Nov/2014:13:26:36 +0200] - Listening on > /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* > *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* > > > > > > On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti wrote: > >> IMHO It's DS bug, can you share DS error log? >> pspacek CCed to examine named logs. >> >> Martin^2 >> >> >> On 11/11/14 12:13, Walter van Lille wrote: >> >> Hi Martin, thanks for the reply. >> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >> The server doesn't have journalctl installed but I have the outputs from >> the messages and named.run files that I included here: >> >> Messages: >> >> *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) >> resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust >> "timeout" parameter* >> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust >> "timeout" parameter* >> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust >> "timeout" parameter* >> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust >> "timeout" parameter* >> >> Named.run: >> >> *client 10.123.123.123#42639: transfer of 'example.example/IN': >> AXFR-style IXFR started* >> *client 10.123.123.123#42639: transfer of ''example.example/IN': >> AXFR-style IXFR ended* >> *client 10.123.123.123#46912: transfer of >> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >> *client 10.123.123.123#46912: transfer of >> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> *LDAP query timed out. Try to adjust "timeout" parameter* >> >> I just replaced the IPs and the actual names with something more >> generic. >> >> Regards, >> >> Walter >> >> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti wrote: >> >>> On 06/11/14 14:58, Walter van Lille wrote: >>> >>> Hi, >>> >>> I need some assistance please. >>> I've taken over an IPA server to manage a few months ago, and it was >>> working fine until recently when it started acting up seemingly off its own >>> accord. >>> When I do an ipactl status it basically gives an output as shown below: >>> >>> >>> >>> *Directory Service: RUNNING * >>> >>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To >>> the tune of 7 minutes sometimes)* >>> >>> *KDC Service: RUNNING* >>> *KPASSWD Service: RUNNING* >>> *DNS Service: RUNNING* >>> *MEMCACHE Service: RUNNING* >>> *HTTP Service: RUNNING* >>> *CA Service: RUNNING* >>> *ADTRUST Service: RUNNING* >>> *EXTID Service: RUNNING* >>> >>> Running top showed that ns-slapd was munching almost all my resources, >>> but I got that fixed by upping the cache. Unfortunately this did not >>> correct the issue and it still reacts in the same fashion, although the >>> resources have been freed up now. >>> I've noticed that when I run dig on either the local server or a remote >>> machine that the query basically just times out as shown here: >>> >>> *dig freeipa.myexample.sample* >>> >>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>> freeipa.myexample.sample* >>> *;; global options: +cmd* >>> *;; connection timed out; no servers could be reached* >>> >>> When the KDC service fails to start, then name lookups seem OK, but >>> authentication fails. otherwise it's dead in the water. >>> >>> This also happens: >>> >>> *sudo ipactl status* >>> *Directory Service: RUNNING* >>> *Unknown error when retrieving list of services from LDAP:* >>> >>> My software setup is as follows: >>> >>> >>> *CentOS release 6.5 (Final) * >>> >>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 * >>> >>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * >>> *bind-dyndb-ldap.x86_64* >>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>> *rpcbind.x86_64 0.2.0-11.el6 >>> @anaconda-CentOS-201311291202.x86_64/6.5* >>> *samba4-winbind.x86_64* >>> >>> *krb5-server.x86_64 1.10.3-15.el6_5.1 * >>> >>> >>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 >>> x86_64 x86_64 x86_64 GNU/Linux * >>> >>> It's not a permanent situation as it sometimes runs 100% for a while, >>> but 80% of the time it is unusable. If anybody can assist me, please be so >>> kind. >>> >>> Regards, >>> >>> Walter >>> >>> Hello please which version of bind-dyndb-ldap do you use? >>> I had similar issue with bind-dyndb-ldap, but it was development >>> version, I'm not sure if this is your case. >>> When named was failing, dirserv was really slow. >>> >>> Can you send journalctl -b -u named log when dig doesn't work?? >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > Martin Basti > > > > > > > > > > -- > Martin Basti > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktracefiles.zip Type: application/zip Size: 7270 bytes Desc: not available URL: From bradford.jonathan at gmail.com Wed Nov 12 13:44:50 2014 From: bradford.jonathan at gmail.com (Jonathan Bradford) Date: Wed, 12 Nov 2014 07:44:50 -0600 Subject: [Freeipa-users] Unable to Login until Trust is Repaired Message-ID: This is my first post on the IPA mailing list. Hey guys :) I've successfully walked through the IdM Red Hat document on "Integrating with Active Directory Through Cross-Realm Kerberos Trusts" using separate DNS domains. I've reached the part where you test the trust using SSH via PuTTY, and I have noticed a problem. If I add a user in Active Directory (group mapping is on), the user cannot immediately SSH to an IPA host. In fact, it never allows me to login until I first login to a Windows machine with the account and then repair the trust via AD. To repair the trust, I have to go to AD Domains and Trusts > Properties > Trusts> and Validate the incoming and outgoing connections. When I do this, it gives me an error message about the RPC server not running, but if I proceed, it eventually tells me that the connection has been repaired. Only after doing this can I successfully SSH with a new user. Do you have any idea why this might be happening? I have followed Red Hat's documentation exactly, so I am not sure why I am having issues. If you have any thoughts or ideas, I would greatly appreciate them. Thanks! -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Nov 12 14:16:24 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 12 Nov 2014 07:16:24 -0700 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> Message-ID: <54636BB8.3080700@redhat.com> On 11/12/2014 05:42 AM, Walter van Lille wrote: > Thanks again for the assistance guys. I have saved two files and > included it here. Hope it tells you more than it does me. These stack traces contain no useful symbols. Please read http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to find out how to install the correct debuginfo packages on your system. For IPA you will also need debuginfo packages for ipa and slapi-nis If debuginfo-install is not working, see https://www.centos.org/forums/viewtopic.php?t=1710 If you simply cannot figure out how to install the debuginfo packages, please email me with the following information: $ rpm -q ipa-server slapi-nis 389-ds-base openldap db4 nss nspr glibc and I will make them available to you NOTE: With debuginfo packages, the version of the debuginfo package _must exactly match_ the version of the associated package e.g. for 389-ds-base.x86_64 1.2.11.15-34.el6_5 you must have 389-ds-base-debuginfo.x86_64 1.2.11.15-34.el6_5 If the versions do not match exactly, you will not get the symbols. > > Regards, > > Wallter > > On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson > wrote: > > On 11/11/2014 10:37 AM, Martin Basti wrote: >> On 11/11/14 15:58, Rich Megginson wrote: >>> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >>>> >>>> On 11/11/2014 02:14 PM, Martin Basti wrote: >>>>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >>>> hmm, it says limit is 2097152, so it already has the new >>>> setting, but the error message says the packet is 800MB* >>>> * >>> >>> *Right. That usually means the server was expecting an >>> encrypted SASL buffer from the client, but instead the client >>> thinks SASL encryption negotiation failed and just sent a plain >>> LDAP buffer. What version of 389-ds-base are you using? rpm -q >>> 389-ds-base >>> >>> https://fedorahosted.org/389/ticket/47416 >>> >>> So, DO NOT increase your sasl io buffer size - it will not fix >>> the problem, and it will leave you open to DoS attacks. >>> * >> >> He is using >> >> CentOS release 6.5 (Final) >> 389-ds-base.x86_64 1.2.11.15-34.el6_5 > > > Ignore the "SASL encrypted packet length exceeds maximum allowed > limit" error. All it means is the client has some error and is > canceling the connection. > > The bugzilla associated with *47416 > is targeted for RHEL > 7.1. The problem is that we were never able to figure out what > error the client was getting that caused the client to stop > establishing the *SASL encryption, and the original customer who > reported the problem dropped the case - everything just started > working, no further errors. Note that 47416 doesn't really fix > the problem or address the root cause - the root cause is some > error on the client side that causes it to stop doing encrypted > SASL I/O and send an LDAP unbind request. > > Let's get back to the actual problem - what is the actual > problem? The ldap server is hanging or unresponsive? If so, then > see > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. > Let's get some dirsrv stack traces during the period of time when > it appears to be unresponsive. > > >> >>> * >>> * >>>> ** >>>>> >>>>> On 11/11/14 13:13, Walter van Lille wrote: >>>>>> I've just cleaned out a ton of slapd_poll timed out messages >>>>>> from the output and changed the names to protect the >>>>>> innocent, :-) >>>>>> Here is the output as requested: >>>>>> >>>>>> >>>>>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length >>>>>> exceeds maximum allowed limit (length=805565, limit=2097152). >>>>>> Change the nsslapd-maxsasliosize attribute in cn=config to >>>>>> increase limit.* >>>>>> * >>>>>> * >>>>>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>>>>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable >>>>>> SASL security on connection in CLOSING state* >>>>>> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove >>>>>> IO layers from connection* >>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - >>>>>> signaling operation threads* >>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting >>>>>> for 30 threads to terminate* >>>>>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing >>>>>> down internal subsystems and plugins* >>>>>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database >>>>>> threads to stop* >>>>>> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >>>>>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>>>>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>>>>> B2014.219.179 starting up* >>>>>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: >>>>>> no entries set up under cn=computers, >>>>>> cn=compat,dc=sample,dc=example* >>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS >>>>>> Templates found, which should be added before the CoS >>>>>> Definition.* >>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS >>>>>> Templates found, which should be added before the CoS >>>>>> Definition.* >>>>>> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on >>>>>> All Interfaces port 389 for LDAP requests* >>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces >>>>>> port 636 for LDAPS requests* >>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>>>>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>>>>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>>>>> * >>>>>> * >>>>>> * >>>>>> * >>>>>> * >>>>>> * >>>>>> >>>>>> >>>>>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >>>>>> > wrote: >>>>>> >>>>>> IMHO It's DS bug, can you share DS error log? >>>>>> pspacek CCed to examine named logs. >>>>>> >>>>>> Martin^2 >>>>>> >>>>>> >>>>>> On 11/11/14 12:13, Walter van Lille wrote: >>>>>>> Hi Martin, thanks for the reply. >>>>>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>>>>> The server doesn't have journalctl installed but I have >>>>>>> the outputs from the messages and named.run files that I >>>>>>> included here: >>>>>>> >>>>>>> Messages: >>>>>>> >>>>>>> *Nov 11 12:30:13 freeipa named[1481]: error (network >>>>>>> unreachable) resolving >>>>>>> 'example.example.com.10.123.123.123/A/IN': >>>>>>> 2001:500:2f::f#53* >>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed >>>>>>> out. Try to adjust "timeout" parameter* >>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed >>>>>>> out. Try to adjust "timeout" parameter* >>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed >>>>>>> out. Try to adjust "timeout" parameter* >>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed >>>>>>> out. Try to adjust "timeout" parameter* >>>>>>> >>>>>>> Named.run: >>>>>>> >>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>> 'example.example/IN': AXFR-style IXFR started* >>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>> ''example.example/IN': AXFR-style IXFR ended* >>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>>>>> >>>>>>> I just replaced the IPs and the actual names with >>>>>>> something more generic. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Walter >>>>>>> >>>>>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>>>>>> > wrote: >>>>>>> >>>>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I need some assistance please. >>>>>>>> I've taken over an IPA server to manage a few >>>>>>>> months ago, and it was working fine until recently >>>>>>>> when it started acting up seemingly off its own accord. >>>>>>>> When I do an ipactl status it basically gives an >>>>>>>> output as shown below: >>>>>>>> >>>>>>>> >>>>>>>> *Directory Service: RUNNING >>>>>>>> * >>>>>>>> * >>>>>>>> * >>>>>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>>>>> pause... (To the tune of 7 minutes sometimes)* >>>>>>>> * >>>>>>>> * >>>>>>>> *KDC Service: RUNNING* >>>>>>>> *KPASSWD Service: RUNNING* >>>>>>>> *DNS Service: RUNNING* >>>>>>>> *MEMCACHE Service: RUNNING* >>>>>>>> *HTTP Service: RUNNING* >>>>>>>> *CA Service: RUNNING* >>>>>>>> *ADTRUST Service: RUNNING* >>>>>>>> *EXTID Service: RUNNING* >>>>>>>> >>>>>>>> Running top showed that ns-slapd was munching >>>>>>>> almost all my resources, but I got that fixed by >>>>>>>> upping the cache. Unfortunately this did not >>>>>>>> correct the issue and it still reacts in the same >>>>>>>> fashion, although the resources have been freed up now. >>>>>>>> I've noticed that when I run dig on either the >>>>>>>> local server or a remote machine that the query >>>>>>>> basically just times out as shown here: >>>>>>>> >>>>>>>> *dig freeipa.myexample.sample* >>>>>>>> * >>>>>>>> * >>>>>>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 >>>>>>>> <<>> freeipa.myexample.sample* >>>>>>>> *;; global options: +cmd* >>>>>>>> *;; connection timed out; no servers could be reached* >>>>>>>> >>>>>>>> When the KDC service fails to start, then name >>>>>>>> lookups seem OK, but authentication fails. >>>>>>>> otherwise it's dead in the water. >>>>>>>> >>>>>>>> This also happens: >>>>>>>> >>>>>>>> *sudo ipactl status* >>>>>>>> *Directory Service: RUNNING* >>>>>>>> *Unknown error when retrieving list of services >>>>>>>> from LDAP:* >>>>>>>> * >>>>>>>> * >>>>>>>> My software setup is as follows: >>>>>>>> >>>>>>>> *CentOS release 6.5 (Final) >>>>>>>> * >>>>>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>>>>> * >>>>>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>>>>> * >>>>>>>> *bind-dyndb-ldap.x86_64* >>>>>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>>>>> *samba4-winbind.x86_64* >>>>>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>>>>> * >>>>>>>> * >>>>>>>> * >>>>>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 >>>>>>>> 21:36:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>> * >>>>>>>> >>>>>>>> It's not a permanent situation as it sometimes runs >>>>>>>> 100% for a while, but 80% of the time it is >>>>>>>> unusable. If anybody can assist me, please be so kind. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Walter >>>>>>>> >>>>>>> Hello please which version of bind-dyndb-ldap do you >>>>>>> use? >>>>>>> I had similar issue with bind-dyndb-ldap, but it was >>>>>>> development version, I'm not sure if this is your case. >>>>>>> When named was failing, dirserv was really slow. >>>>>>> >>>>>>> Can you send journalctl -b -u named log when dig >>>>>>> doesn't work?? >>>>>>> >>>>>>> -- >>>>>>> Martin Basti >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Martin Basti >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> Martin Basti >> >> > > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.ladanyi at kit.edu Wed Nov 12 14:54:14 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Wed, 12 Nov 2014 15:54:14 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS Message-ID: <54637496.9030508@kit.edu> Hi, I set up the 389 LDAP server to support des-cbc-crc enctype. I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 (single-DES). I created the principal with: kadmin.local -x ipa-setup-override-restrictions The result is: Principal: afs/cellname at Realm Key: vno 1, des-cbc-crc, no salt Key: vno 1, aes256-cts-hmac-sha1-96, no salt Seems like the principal was set correctly with single-des. I execute a "kinit username" and got my tgt. kvno -e des-cbc-crc afs/cellname kvno: KDC has no support for encryption type while getting credentials for afs/cellname at REALM kvno -e aes256-cts-hmac-sha1-96 afs/cellname afs/cellname at PP.IPD.KIT.EDU: kvno = 1 Iam wondering that i dont get a ticket with des-cbc-crc enctype from FreeIPA Kerberos server. Any ideas ? cheers, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5306 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Wed Nov 12 19:42:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Nov 2014 14:42:51 -0500 Subject: [Freeipa-users] Unable to Login until Trust is Repaired In-Reply-To: References: Message-ID: <5463B83B.1040601@redhat.com> On 11/12/2014 08:44 AM, Jonathan Bradford wrote: > This is my first post on the IPA mailing list. Hey guys :) > I've successfully walked through the IdM Red Hat document on > "Integrating with Active Directory Through Cross-Realm Kerberos > Trusts" using separate DNS domains. I've reached the part where you > test the trust using SSH via PuTTY, and I have noticed a problem. > If I add a user in Active Directory (group mapping is on), the user > cannot immediately SSH to an IPA host. In fact, it never allows me to > login until I first login to a Windows machine with the account and > then repair the trust via AD. > To repair the trust, I have to go to AD Domains and Trusts > > Properties > Trusts> and Validate the incoming and outgoing > connections. When I do this, it gives me an error message about the > RPC server not running, but if I proceed, it eventually tells me that > the connection has been repaired. Only after doing this can I > successfully SSH with a new user. > Do you have any idea why this might be happening? I have followed Red > Hat's documentation exactly, so I am not sure why I am having issues. > If you have any thoughts or ideas, I would greatly appreciate them. > Thanks! > -Jonathan > > HI Jonathan, I would leave to Alexander to drill down into the details when he is back online tomorrow however if the trust is not validated then it is not fully established the first time. Something when wrong and it would be nice to look at the logs on the IPA and AD side to be able to determine the cause. Do you need to repair the trust for every single user or just once? What it is your AD domain topology? Are you establishing trust with the primary domain controller? What version of IPA and AD are you using? Thanks Dmitri -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Nov 12 19:45:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Nov 2014 14:45:10 -0500 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <54637496.9030508@kit.edu> References: <54637496.9030508@kit.edu> Message-ID: <5463B8C6.1020105@redhat.com> On 11/12/2014 09:54 AM, Andreas Ladanyi wrote: > Hi, > > I set up the 389 LDAP server to support des-cbc-crc enctype. > > I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 > (single-DES). I created the principal with: > > kadmin.local -x ipa-setup-override-restrictions > > The result is: > > Principal: afs/cellname at Realm > Key: vno 1, des-cbc-crc, no salt > Key: vno 1, aes256-cts-hmac-sha1-96, no salt > > Seems like the principal was set correctly with single-des. > > I execute a "kinit username" and got my tgt. > > kvno -e des-cbc-crc afs/cellname > kvno: KDC has no support for encryption type while getting credentials > for afs/cellname at REALM > > kvno -e aes256-cts-hmac-sha1-96 afs/cellname > afs/cellname at PP.IPD.KIT.EDU: kvno = 1 > > Iam wondering that i dont get a ticket with des-cbc-crc enctype from > FreeIPA Kerberos server. > > Any ideas ? > > > cheers, > Andreas > > > > Did you enable use of weak crypto? See allow_weak_crypto setting in krb5.conf on the server. http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Nov 13 01:17:45 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 12 Nov 2014 20:17:45 -0500 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <54637496.9030508@kit.edu> References: <54637496.9030508@kit.edu> Message-ID: <20141112201745.31eeab14@willson.usersys.redhat.com> On Wed, 12 Nov 2014 15:54:14 +0100 Andreas Ladanyi wrote: > Hi, > > I set up the 389 LDAP server to support des-cbc-crc enctype. > > I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 > (single-DES). I created the principal with: > > kadmin.local -x ipa-setup-override-restrictions Please don't do this, use the ipa service-add and ipa-getkeytab commands instead. > The result is: > > Principal: afs/cellname at Realm > Key: vno 1, des-cbc-crc, no salt > Key: vno 1, aes256-cts-hmac-sha1-96, no salt > > Seems like the principal was set correctly with single-des. > > I execute a "kinit username" and got my tgt. > > kvno -e des-cbc-crc afs/cellname > kvno: KDC has no support for encryption type while getting credentials > for afs/cellname at REALM > > kvno -e aes256-cts-hmac-sha1-96 afs/cellname > afs/cellname at PP.IPD.KIT.EDU: kvno = 1 > > Iam wondering that i dont get a ticket with des-cbc-crc enctype from > FreeIPA Kerberos server. > > Any ideas ? des-cbc-crc is disabled at different levels, you need to set allow_weak_crypro = yes in krb5.conf to enabled use of DES algorithms at all. On the KDC however you also need to change the list of allowed enctypes in LDAP and in the KDC configuration file. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Nov 13 07:37:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Nov 2014 08:37:45 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <20141112201745.31eeab14@willson.usersys.redhat.com> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> Message-ID: <54645FC9.4040709@redhat.com> On 13.11.2014 02:17, Simo Sorce wrote: > On Wed, 12 Nov 2014 15:54:14 +0100 > Andreas Ladanyi wrote: > >> Hi, >> >> I set up the 389 LDAP server to support des-cbc-crc enctype. >> >> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 >> (single-DES). I created the principal with: >> >> kadmin.local -x ipa-setup-override-restrictions > > Please don't do this, use the ipa service-add and ipa-getkeytab > commands instead. > >> The result is: >> >> Principal: afs/cellname at Realm >> Key: vno 1, des-cbc-crc, no salt >> Key: vno 1, aes256-cts-hmac-sha1-96, no salt >> >> Seems like the principal was set correctly with single-des. >> >> I execute a "kinit username" and got my tgt. >> >> kvno -e des-cbc-crc afs/cellname >> kvno: KDC has no support for encryption type while getting credentials >> for afs/cellname at REALM >> >> kvno -e aes256-cts-hmac-sha1-96 afs/cellname >> afs/cellname at PP.IPD.KIT.EDU: kvno = 1 >> >> Iam wondering that i dont get a ticket with des-cbc-crc enctype from >> FreeIPA Kerberos server. >> >> Any ideas ? > > des-cbc-crc is disabled at different levels, you need to set It should be noted that there are very good reasons for disabling des-cbc-crc: *It is completely insecure* and can be cracked easily! > allow_weak_crypro = yes in krb5.conf to enabled use of DES algorithms > at all. > On the KDC however you also need to change the list of allowed > enctypes in LDAP and in the KDC configuration file. -- Petr^2 Spacek From andreas.ladanyi at kit.edu Thu Nov 13 08:47:30 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Thu, 13 Nov 2014 09:47:30 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <20141112201745.31eeab14@willson.usersys.redhat.com> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> Message-ID: <54647022.1070004@kit.edu> >> Hi, >> >> I set up the 389 LDAP server to support des-cbc-crc enctype. >> >> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 >> (single-DES). I created the principal with: >> >> kadmin.local -x ipa-setup-override-restrictions > Please don't do this, use the ipa service-add and ipa-getkeytab > commands instead. I cant use ipa service-add, because for OpenAFS i need a service principal called: afs/cellname at REALM , the cellname could be any name. In my case the cellname is the same like the domainname. With ipa service-add i could only add principals like service/FQDN at REALM. > >> The result is: >> >> Principal: afs/cellname at Realm >> Key: vno 1, des-cbc-crc, no salt >> Key: vno 1, aes256-cts-hmac-sha1-96, no salt >> >> Seems like the principal was set correctly with single-des. >> >> I execute a "kinit username" and got my tgt. >> >> kvno -e des-cbc-crc afs/cellname >> kvno: KDC has no support for encryption type while getting credentials >> for afs/cellname at REALM >> >> kvno -e aes256-cts-hmac-sha1-96 afs/cellname >> afs/cellname at PP.IPD.KIT.EDU: kvno = 1 >> >> Iam wondering that i dont get a ticket with des-cbc-crc enctype from >> FreeIPA Kerberos server. >> >> Any ideas ? > des-cbc-crc is disabled at different levels, you need to set > allow_weak_crypro = yes in krb5.conf to enabled use of DES algorithms > at all. I have already done this on the client side. > On the KDC however you also need to change the list of allowed > enctypes in LDAP and in the KDC configuration file. ok, i already add the supportedenctypes and defaultencsalttypes in the 389 LDAP enctype list of the kerberos realm. In which KDC file do i have to change the enctypes on FreeIPA server ? kdc.conf ? What should i add to get the FreeIPA KDC delivering single-des ? > > Simo. > cheers, Andreas From abokovoy at redhat.com Thu Nov 13 09:35:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Nov 2014 11:35:53 +0200 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <54647022.1070004@kit.edu> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> Message-ID: <20141113093553.GE3493@redhat.com> On Thu, 13 Nov 2014, Andreas Ladanyi wrote: >>> Hi, >>> >>> I set up the 389 LDAP server to support des-cbc-crc enctype. >>> >>> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 >>> (single-DES). I created the principal with: >>> >>> kadmin.local -x ipa-setup-override-restrictions >> Please don't do this, use the ipa service-add and ipa-getkeytab >> commands instead. >I cant use ipa service-add, because for OpenAFS i need a service >principal called: > >afs/cellname at REALM , the cellname could be any name. In my case the >cellname is the same like the domainname. [root at cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test --------------------------------------- Added host "afs-cellname.ipacloud.test" --------------------------------------- Host name: afs-cellname.ipacloud.test Principal name: host/afs-cellname.ipacloud.test at IPACLOUD.TEST Password: False Keytab: False Managed by: afs-cellname.ipacloud.test [root at cc21 ~]# ipa service-add --force afs/afs-cellname ---------------------------------------------- Added service "afs/afs-cellname at IPACLOUD.TEST" ---------------------------------------------- Principal: afs/afs-cellname at IPACLOUD.TEST Managed by: afs-cellname.ipacloud.test [root at cc21 ~]# ipa service-show afs/afs-cellname Principal: afs/afs-cellname at IPACLOUD.TEST Keytab: False Managed by: afs-cellname.ipacloud.test [root at cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname -k /tmp/afs.keytab Keytab successfully retrieved and stored in: /tmp/afs.keytab As you can see there is no problem at all -- all you need is to have a host entry with the same name as afs-cellname. Note that the host afs-cellname doesn't even need to exist in DNS. However, your primary problem would be in a different area. You'll need to enable weak crypto at KDC server, Kerberos clients, and LDAP servers. krb5.conf (on both IPA masters and clients): [libdefaults] allow_weak_crypto = true /var/kerberos/krb5kdc/kdc.conf (on IPA masters): [realms] IPACLOUD.TEST = { supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal des-cbc-crc:v4 } Finally, you need to modify cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test and add des-cbc-crc:v4 to supported Kerberos encryption types with krbSupportedEncSaltTypes attribute. You have to use ldapmodify as cn=Directory Manager for that as we don't allow admins to modify these entries directly. A simplified approach would be to use ipa-ldap-updater with your own update file (which should have a name like -.update where is something between 01 and 90): [root at cc21 ~]# cat 20-weak-enctypes.update dn: cn=$REALM,cn=kerberos,$SUFFIX add: krbSupportedEncSaltTypes: des-cbc-crc:v4 [root at cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory Manager password: Parsing update file './20-weak-enctypes.update' Updating existing entry: cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test Done The ipa-ldap-updater command was successful Only after that you'll get ipa-getkeytab to generate weaker encryption type-based keys. However, we have a problem in FreeIPA 4.x that an attempt to force only a specific encryption type in ipa-getkeytab is ignored and instead only enctypes from krbDefaultEncSaltTypes attribute are generated. This bug is tracked with https://fedorahosted.org/freeipa/ticket/4718 -- / Alexander Bokovoy From walter.van.lille at gmail.com Thu Nov 13 10:02:03 2014 From: walter.van.lille at gmail.com (Walter van Lille) Date: Thu, 13 Nov 2014 12:02:03 +0200 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54636BB8.3080700@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> <54636BB8.3080700@redhat.com> Message-ID: Thanks Rich, I have installed the packages and run gdb again. Hopefully the attached file is more useful. On Wed, Nov 12, 2014 at 4:16 PM, Rich Megginson wrote: > On 11/12/2014 05:42 AM, Walter van Lille wrote: > > Thanks again for the assistance guys. I have saved two files and included > it here. Hope it tells you more than it does me. > > > These stack traces contain no useful symbols. > > Please read > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to find > out how to install the correct debuginfo packages on your system. For IPA > you will also need debuginfo packages for ipa and slapi-nis > > If debuginfo-install is not working, see > https://www.centos.org/forums/viewtopic.php?t=1710 > > If you simply cannot figure out how to install the debuginfo packages, > please email me with the following information: > > $ rpm -q ipa-server slapi-nis 389-ds-base openldap db4 nss nspr glibc > > and I will make them available to you > > NOTE: With debuginfo packages, the version of the debuginfo package _must > exactly match_ the version of the associated package e.g. for 389-ds-base.x86_64 > 1.2.11.15-34.el6_5 you must have > 389-ds-base-debuginfo.x86_64 1.2.11.15-34.el6_5 > > If the versions do not match exactly, you will not get the symbols. > > > Regards, > > Wallter > > On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson > wrote: > >> On 11/11/2014 10:37 AM, Martin Basti wrote: >> >> On 11/11/14 15:58, Rich Megginson wrote: >> >> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >> >> >> On 11/11/2014 02:14 PM, Martin Basti wrote: >> >> Ludiwg (CCed) this seems like old (fixed?) DS bug. >> >> hmm, it says limit is 2097152, so it already has the new setting, but the >> error message says the packet is 800MB >> >> >> >> >> >> >> >> *Right. That usually means the server was expecting an encrypted SASL >> buffer from the client, but instead the client thinks SASL encryption >> negotiation failed and just sent a plain LDAP buffer. What version of >> 389-ds-base are you using? rpm -q 389-ds-base >> https://fedorahosted.org/389/ticket/47416 >> So, DO NOT increase your sasl >> io buffer size - it will not fix the problem, and it will leave you open to >> DoS attacks. * >> >> >> He is using >> >> CentOS release 6.5 (Final) >> 389-ds-base.x86_64 1.2.11.15-34.el6_5 >> >> >> >> Ignore the "SASL encrypted packet length exceeds maximum allowed limit" >> error. All it means is the client has some error and is canceling the >> connection. >> >> The bugzilla associated with *47416 >> is targeted for RHEL 7.1. The >> problem is that we were never able to figure out what error the client was >> getting that caused the client to stop establishing the *SASL >> encryption, and the original customer who reported the problem dropped the >> case - everything just started working, no further errors. Note that 47416 >> doesn't really fix the problem or address the root cause - the root cause >> is some error on the client side that causes it to stop doing encrypted >> SASL I/O and send an LDAP unbind request. >> >> Let's get back to the actual problem - what is the actual problem? The >> ldap server is hanging or unresponsive? If so, then see >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. Let's >> get some dirsrv stack traces during the period of time when it appears to >> be unresponsive. >> >> >> >> >> >> On 11/11/14 13:13, Walter van Lille wrote: >> >> I've just cleaned out a ton of slapd_poll timed out messages from the >> output and changed the names to protect the innocent, :-) >> Here is the output as requested: >> >> >> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds >> maximum allowed limit (length=805565, limit=2097152). Change the >> nsslapd-maxsasliosize attribute in cn=config to increase limit.* >> >> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >> security on connection in CLOSING state* >> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers >> from connection* >> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >> operation threads* >> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 >> threads to terminate* >> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >> internal subsystems and plugins* >> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* >> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >> B2014.219.179 starting up* >> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries >> set up under cn=computers, cn=compat,dc=sample,dc=example* >> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which >> should be added before the CoS Definition.* >> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which >> should be added before the CoS Definition.* >> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests* >> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for >> LDAPS requests* >> *[11/Nov/2014:13:26:36 +0200] - Listening on >> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >> >> >> >> >> >> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti wrote: >> >>> IMHO It's DS bug, can you share DS error log? >>> pspacek CCed to examine named logs. >>> >>> Martin^2 >>> >>> >>> On 11/11/14 12:13, Walter van Lille wrote: >>> >>> Hi Martin, thanks for the reply. >>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>> The server doesn't have journalctl installed but I have the outputs from >>> the messages and named.run files that I included here: >>> >>> Messages: >>> >>> *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) >>> resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to >>> adjust "timeout" parameter* >>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to >>> adjust "timeout" parameter* >>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to >>> adjust "timeout" parameter* >>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to >>> adjust "timeout" parameter* >>> >>> Named.run: >>> >>> *client 10.123.123.123#42639: transfer of 'example.example/IN': >>> AXFR-style IXFR started* >>> *client 10.123.123.123#42639: transfer of ''example.example/IN': >>> AXFR-style IXFR ended* >>> *client 10.123.123.123#46912: transfer of >>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>> *client 10.123.123.123#46912: transfer of >>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> *LDAP query timed out. Try to adjust "timeout" parameter* >>> >>> I just replaced the IPs and the actual names with something more >>> generic. >>> >>> Regards, >>> >>> Walter >>> >>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti wrote: >>> >>>> On 06/11/14 14:58, Walter van Lille wrote: >>>> >>>> Hi, >>>> >>>> I need some assistance please. >>>> I've taken over an IPA server to manage a few months ago, and it was >>>> working fine until recently when it started acting up seemingly off its own >>>> accord. >>>> When I do an ipactl status it basically gives an output as shown below: >>>> >>>> >>>> >>>> *Directory Service: RUNNING * >>>> >>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To >>>> the tune of 7 minutes sometimes)* >>>> >>>> *KDC Service: RUNNING* >>>> *KPASSWD Service: RUNNING* >>>> *DNS Service: RUNNING* >>>> *MEMCACHE Service: RUNNING* >>>> *HTTP Service: RUNNING* >>>> *CA Service: RUNNING* >>>> *ADTRUST Service: RUNNING* >>>> *EXTID Service: RUNNING* >>>> >>>> Running top showed that ns-slapd was munching almost all my >>>> resources, but I got that fixed by upping the cache. Unfortunately this did >>>> not correct the issue and it still reacts in the same fashion, although the >>>> resources have been freed up now. >>>> I've noticed that when I run dig on either the local server or a remote >>>> machine that the query basically just times out as shown here: >>>> >>>> *dig freeipa.myexample.sample* >>>> >>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>> freeipa.myexample.sample* >>>> *;; global options: +cmd* >>>> *;; connection timed out; no servers could be reached* >>>> >>>> When the KDC service fails to start, then name lookups seem OK, but >>>> authentication fails. otherwise it's dead in the water. >>>> >>>> This also happens: >>>> >>>> *sudo ipactl status* >>>> *Directory Service: RUNNING* >>>> *Unknown error when retrieving list of services from LDAP:* >>>> >>>> My software setup is as follows: >>>> >>>> >>>> *CentOS release 6.5 (Final) * >>>> >>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 * >>>> >>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * >>>> *bind-dyndb-ldap.x86_64* >>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>> *rpcbind.x86_64 0.2.0-11.el6 >>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>> *samba4-winbind.x86_64* >>>> >>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 * >>>> >>>> >>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 >>>> x86_64 x86_64 x86_64 GNU/Linux * >>>> >>>> It's not a permanent situation as it sometimes runs 100% for a while, >>>> but 80% of the time it is unusable. If anybody can assist me, please be so >>>> kind. >>>> >>>> Regards, >>>> >>>> Walter >>>> >>>> Hello please which version of bind-dyndb-ldap do you use? >>>> I had similar issue with bind-dyndb-ldap, but it was development >>>> version, I'm not sure if this is your case. >>>> When named was failing, dirserv was really slow. >>>> >>>> Can you send journalctl -b -u named log when dig doesn't work?? >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> Martin Basti >> >> >> >> >> >> >> >> >> >> -- >> Martin Basti >> >> >> >> >> >> -- >> 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktrace.1415871697.zip Type: application/zip Size: 8953 bytes Desc: not available URL: From lkrispen at redhat.com Thu Nov 13 10:27:02 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 13 Nov 2014 11:27:02 +0100 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> <54636BB8.3080700@redhat.com> Message-ID: <54648776.3090801@redhat.com> Hmm, the symbols are there now, but all threads are idle, DS is just waiting on work to do. Which client do you expect to connect to DS, maybe you need to debug this client. On 11/13/2014 11:02 AM, Walter van Lille wrote: > Thanks Rich, I have installed the packages and run gdb again. > Hopefully the attached file is more useful. > > On Wed, Nov 12, 2014 at 4:16 PM, Rich Megginson > wrote: > > On 11/12/2014 05:42 AM, Walter van Lille wrote: >> Thanks again for the assistance guys. I have saved two files and >> included it here. Hope it tells you more than it does me. > > These stack traces contain no useful symbols. > > Please read > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > to find out how to install the correct debuginfo packages on your > system. For IPA you will also need debuginfo packages for ipa and > slapi-nis > > If debuginfo-install is not working, see > https://www.centos.org/forums/viewtopic.php?t=1710 > > If you simply cannot figure out how to install the debuginfo > packages, please email me with the following information: > > $ rpm -q ipa-server slapi-nis 389-ds-base openldap db4 nss nspr glibc > > and I will make them available to you > > NOTE: With debuginfo packages, the version of the debuginfo > package _must exactly match_ the version of the associated package > e.g. for 389-ds-base.x86_64 1.2.11.15-34.el6_5 you must have > 389-ds-base-debuginfo.x86_64 1.2.11.15-34.el6_5 > > If the versions do not match exactly, you will not get the symbols. > >> >> Regards, >> >> Wallter >> >> On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson >> > wrote: >> >> On 11/11/2014 10:37 AM, Martin Basti wrote: >>> On 11/11/14 15:58, Rich Megginson wrote: >>>> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >>>>> >>>>> On 11/11/2014 02:14 PM, Martin Basti wrote: >>>>>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >>>>> hmm, it says limit is 2097152, so it already has the new >>>>> setting, but the error message says the packet is 800MB* >>>>> * >>>> >>>> *Right. That usually means the server was expecting an >>>> encrypted SASL buffer from the client, but instead the >>>> client thinks SASL encryption negotiation failed and just >>>> sent a plain LDAP buffer. What version of 389-ds-base are >>>> you using? rpm -q 389-ds-base >>>> >>>> https://fedorahosted.org/389/ticket/47416 >>>> >>>> So, DO NOT increase your sasl io buffer size - it will not >>>> fix the problem, and it will leave you open to DoS attacks. >>>> * >>> >>> He is using >>> >>> CentOS release 6.5 (Final) >>> 389-ds-base.x86_64 1.2.11.15-34.el6_5 >> >> >> Ignore the "SASL encrypted packet length exceeds maximum >> allowed limit" error. All it means is the client has some >> error and is canceling the connection. >> >> The bugzilla associated with *47416 >> is targeted for >> RHEL 7.1. The problem is that we were never able to figure >> out what error the client was getting that caused the client >> to stop establishing the *SASL encryption, and the original >> customer who reported the problem dropped the case - >> everything just started working, no further errors. Note >> that 47416 doesn't really fix the problem or address the root >> cause - the root cause is some error on the client side that >> causes it to stop doing encrypted SASL I/O and send an LDAP >> unbind request. >> >> Let's get back to the actual problem - what is the actual >> problem? The ldap server is hanging or unresponsive? If so, >> then see >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. >> Let's get some dirsrv stack traces during the period of time >> when it appears to be unresponsive. >> >> >>> >>>> * >>>> * >>>>> ** >>>>>> >>>>>> On 11/11/14 13:13, Walter van Lille wrote: >>>>>>> I've just cleaned out a ton of slapd_poll timed out >>>>>>> messages from the output and changed the names to >>>>>>> protect the innocent, :-) >>>>>>> Here is the output as requested: >>>>>>> >>>>>>> >>>>>>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet >>>>>>> length exceeds maximum allowed limit (length=805565, >>>>>>> limit=2097152). Change the nsslapd-maxsasliosize >>>>>>> attribute in cn=config to increase limit.* >>>>>>> * >>>>>>> * >>>>>>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>>>>>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot >>>>>>> enable SASL security on connection in CLOSING state* >>>>>>> *[10/Nov/2014:14:45:19 +0200] - Error: could not >>>>>>> add/remove IO layers from connection* >>>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - >>>>>>> signaling operation threads* >>>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - >>>>>>> waiting for 30 threads to terminate* >>>>>>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - >>>>>>> closing down internal subsystems and plugins* >>>>>>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database >>>>>>> threads to stop* >>>>>>> *[11/Nov/2014:13:14:13 +0200] - All database threads now >>>>>>> stopped* >>>>>>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>>>>>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>>>>>> B2014.219.179 starting up* >>>>>>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - >>>>>>> warning: no entries set up under cn=computers, >>>>>>> cn=compat,dc=sample,dc=example* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no >>>>>>> CoS Templates found, which should be added before the >>>>>>> CoS Definition.* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no >>>>>>> CoS Templates found, which should be added before the >>>>>>> CoS Definition.* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - slapd started. >>>>>>> Listening on All Interfaces port 389 for LDAP requests* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on All >>>>>>> Interfaces port 636 for LDAPS requests* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>>>>>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>>>>>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >>>>>>> > wrote: >>>>>>> >>>>>>> IMHO It's DS bug, can you share DS error log? >>>>>>> pspacek CCed to examine named logs. >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>>> >>>>>>> On 11/11/14 12:13, Walter van Lille wrote: >>>>>>>> Hi Martin, thanks for the reply. >>>>>>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>>>>>> The server doesn't have journalctl installed but I >>>>>>>> have the outputs from the messages and named.run >>>>>>>> files that I included here: >>>>>>>> >>>>>>>> Messages: >>>>>>>> >>>>>>>> *Nov 11 12:30:13 freeipa named[1481]: error >>>>>>>> (network unreachable) resolving >>>>>>>> 'example.example.com.10.123.123.123/A/IN': >>>>>>>> 2001:500:2f::f#53* >>>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> >>>>>>>> Named.run: >>>>>>>> >>>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>>> 'example.example/IN': AXFR-style IXFR started* >>>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>>> ''example.example/IN': AXFR-style IXFR ended* >>>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR >>>>>>>> started* >>>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR >>>>>>>> ended* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> >>>>>>>> I just replaced the IPs and the actual names with >>>>>>>> something more generic. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Walter >>>>>>>> >>>>>>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>>>>>>> > wrote: >>>>>>>> >>>>>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I need some assistance please. >>>>>>>>> I've taken over an IPA server to manage a few >>>>>>>>> months ago, and it was working fine until >>>>>>>>> recently when it started acting up seemingly >>>>>>>>> off its own accord. >>>>>>>>> When I do an ipactl status it basically gives >>>>>>>>> an output as shown below: >>>>>>>>> >>>>>>>>> >>>>>>>>> *Directory Service: RUNNING >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>>>>>> pause... (To the tune of 7 minutes sometimes)* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *KDC Service: RUNNING* >>>>>>>>> *KPASSWD Service: RUNNING* >>>>>>>>> *DNS Service: RUNNING* >>>>>>>>> *MEMCACHE Service: RUNNING* >>>>>>>>> *HTTP Service: RUNNING* >>>>>>>>> *CA Service: RUNNING* >>>>>>>>> *ADTRUST Service: RUNNING* >>>>>>>>> *EXTID Service: RUNNING* >>>>>>>>> >>>>>>>>> Running top showed that ns-slapd was munching >>>>>>>>> almost all my resources, but I got that fixed >>>>>>>>> by upping the cache. Unfortunately this did >>>>>>>>> not correct the issue and it still reacts in >>>>>>>>> the same fashion, although the resources have >>>>>>>>> been freed up now. >>>>>>>>> I've noticed that when I run dig on either the >>>>>>>>> local server or a remote machine that the >>>>>>>>> query basically just times out as shown here: >>>>>>>>> >>>>>>>>> *dig freeipa.myexample.sample* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *; <<>> DiG >>>>>>>>> 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>>>>>> freeipa.myexample.sample* >>>>>>>>> *;; global options: +cmd* >>>>>>>>> *;; connection timed out; no servers could be >>>>>>>>> reached* >>>>>>>>> >>>>>>>>> When the KDC service fails to start, then name >>>>>>>>> lookups seem OK, but authentication fails. >>>>>>>>> otherwise it's dead in the water. >>>>>>>>> >>>>>>>>> This also happens: >>>>>>>>> >>>>>>>>> *sudo ipactl status* >>>>>>>>> *Directory Service: RUNNING* >>>>>>>>> *Unknown error when retrieving list of >>>>>>>>> services from LDAP:* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> My software setup is as follows: >>>>>>>>> >>>>>>>>> *CentOS release 6.5 (Final) >>>>>>>>> * >>>>>>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>>>>>> * >>>>>>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>>>>>> * >>>>>>>>> *bind-dyndb-ldap.x86_64* >>>>>>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>>>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>>>>>> *samba4-winbind.x86_64* >>>>>>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue >>>>>>>>> Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 >>>>>>>>> GNU/Linux >>>>>>>>> * >>>>>>>>> >>>>>>>>> It's not a permanent situation as it sometimes >>>>>>>>> runs 100% for a while, but 80% of the time it >>>>>>>>> is unusable. If anybody can assist me, please >>>>>>>>> be so kind. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Walter >>>>>>>>> >>>>>>>> Hello please which version of bind-dyndb-ldap >>>>>>>> do you use? >>>>>>>> I had similar issue with bind-dyndb-ldap, but >>>>>>>> it was development version, I'm not sure if >>>>>>>> this is your case. >>>>>>>> When named was failing, dirserv was really slow. >>>>>>>> >>>>>>>> Can you send journalctl -b -u named log when >>>>>>>> dig doesn't work?? >>>>>>>> >>>>>>>> -- >>>>>>>> Martin Basti >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Martin Basti >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> 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 >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From unitaip at gmail.com Thu Nov 13 12:14:51 2014 From: unitaip at gmail.com (=?UTF-8?B?0KHQsNC/0LXQs9C40L0g0JLQsNC70LXRgNC40Lk=?=) Date: Thu, 13 Nov 2014 16:14:51 +0400 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD Message-ID: Hi Rich! I turned on the log and see the following records [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): State: start_backoff -> backoff [13/Nov/2014:14:27:02 +0300] - acquire_replica, supplier RUV: [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - supplier: {replicageneration} 5440f039000000030000 [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - supplier: {replica 3 ldap://ipa.test-csbi-its.ru:389} 5440f039000100030000 5464956e000000030000 5464956e [13/Nov/2014:14:27:02 +0300] - acquire_replica, consumer RUV: [13/Nov/2014:14:27:02 +0300] - acquire_replica, consumer RUV = null [13/Nov/2014:14:27:02 +0300] - acquire_replica, supplier RUV is newer [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Cancelling linger on the connection [13/Nov/2014:14:27:02 +0300] - _csngen_adjust_local_time: gen state before 546495820001:1415878018:0:0 [13/Nov/2014:14:27:02 +0300] - _csngen_adjust_local_time: gen state after 546495860000:1415878022:0:0 [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): State: backoff -> sending_updates [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update vector. It has never been initialized. [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Beginning linger on the connection [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - agmt="cn= meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): State: sending_updates -> start_backoff Best regards, Valeriy On 10/29/2014 03:19 AM, ??????? ??????? wrote: Yes Dmitri, ldapsearch works good: [root ipa ~]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-TEST-CSBI-ITS-RU/ ldapsearch -xLLL -ZZ -h csbi-it-dc01.csbigroup.ru -D "cn=ipa-test,cn=users,dc=csbigroup,dc=ru" -w "ttttttttt" -s base -b "cn=users,dc=csbigroup,dc=ru" dn: cn=users,dc=csbigroup,dc=ru objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=csbigroup,DC=ru instanceType: 4 ... ... Ok. Now try to do a windows sync with the dirsrv replication error log level - http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting Then we can take a look at the detailed errors. ? ?????????, ??????? ??????? 2014-10-23 16:19 GMT+04:00 ??????? ??????? : > Hello! > > I tryed to configure synchronization between FreeIPA and Windows AD > 2012. In the thirst time accounts from AD synchronization properly but next > schedule after 5 min is not work and in error log I see the following > errors: > > # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors > [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - agmt="cn= > meTocsbi-it-dc01.csbigroup.ru" (csbi-it-dc01:389): Replica has no update > vector. It has never been initialized. > > Thirst synchronization out > > Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to certificate > database for ipa.test-csbi-its.ru > ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru > Windows PassSync entry exists, not resetting password > ipa: INFO: Added new sync agreement, waiting for it to become ready . . . > ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica > acquired successfully: Incremental update started: start: 0: end: 0 > ipa: INFO: Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update in progress, 13 seconds elapsed > [ipa.test-csbi-its.ru] reports: Update failed! Status: [-1 Total update > abortedLDAP error: Can't contact LDAP server] > > Failed to start replication > > > > FreeIPA server version 3.3.3 > OS version Centos 7 > AD Domain 2012 > > Can you help me to resolve this problem? > > Best regards, Valeriy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.jonathan at gmail.com Thu Nov 13 13:15:05 2014 From: bradford.jonathan at gmail.com (Jonathan Bradford) Date: Thu, 13 Nov 2014 07:15:05 -0600 Subject: [Freeipa-users] Unable to Login until Trust is Repaired (Jonathan) Message-ID: Dmitri: Thanks for the reply. > Do you need to repair the trust for every single user or just once? Yes, I have to repair the trust for every new user added to Active Directory who needs access to an IdM resource. Only once per user though. > What it is your AD domain topology? My AD topology is very simple at the moment because it is a test environment. I currently have one domain controller with a domain of venus.com. My IdM topology is very similar--one IdM server with a domain of mercury.com. > Are you establishing trust with the primary domain controller? Yes. > What version of IPA and AD are you using? I'm using IPA v 3.0. I'm not sure of the current version of AD, but I'm using it on Windows Server 2008 R2 SP1. ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Nov 2014 14:42:51 -0500 From: Dmitri Pal To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to Login until Trust is Repaired Message-ID: <5463B83B.1040601 at redhat.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" On 11/12/2014 08:44 AM, Jonathan Bradford wrote: > This is my first post on the IPA mailing list. Hey guys :) > I've successfully walked through the IdM Red Hat document on > "Integrating with Active Directory Through Cross-Realm Kerberos > Trusts" using separate DNS domains. I've reached the part where you > test the trust using SSH via PuTTY, and I have noticed a problem. > If I add a user in Active Directory (group mapping is on), the user > cannot immediately SSH to an IPA host. In fact, it never allows me to > login until I first login to a Windows machine with the account and > then repair the trust via AD. > To repair the trust, I have to go to AD Domains and Trusts > > Properties > Trusts> and Validate the incoming and outgoing > connections. When I do this, it gives me an error message about the > RPC server not running, but if I proceed, it eventually tells me that > the connection has been repaired. Only after doing this can I > successfully SSH with a new user. > Do you have any idea why this might be happening? I have followed Red > Hat's documentation exactly, so I am not sure why I am having issues. > If you have any thoughts or ideas, I would greatly appreciate them. > Thanks! > -Jonathan > > HI Jonathan, I would leave to Alexander to drill down into the details when he is back online tomorrow however if the trust is not validated then it is not fully established the first time. Something when wrong and it would be nice to look at the logs on the IPA and AD side to be able to determine the cause. Do you need to repair the trust for every single user or just once? What it is your AD domain topology? Are you establishing trust with the primary domain controller? What version of IPA and AD are you using? Thanks Dmitri -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 13 13:27:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Nov 2014 08:27:28 -0500 Subject: [Freeipa-users] Unable to Login until Trust is Repaired (Jonathan) In-Reply-To: References: Message-ID: <5464B1C0.1070709@redhat.com> On 11/13/2014 08:15 AM, Jonathan Bradford wrote: > Dmitri: > Thanks for the reply. > > Do you need to repair the trust for every single user or just once? > Yes, I have to repair the trust for every new user added to Active > Directory who needs access to an IdM resource. Only once per user though. > > What it is your AD domain topology? > My AD topology is very simple at the moment because it is a test > environment. I currently have one domain controller with a domain of > venus.com . My IdM topology is very similar--one > IdM server with a domain of mercury.com . > > Are you establishing trust with the primary domain controller? > Yes. > > What version of IPA and AD are you using? > I'm using IPA v 3.0. I'm not sure of the current version of AD, but > I'm using it on Windows Server 2008 R2 SP1. 3.0 is a pretty old version, I mean a lot has changed in trust area between 3.0 and 3.3. Any chance you can use that? What distro do you use? > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 12 Nov 2014 14:42:51 -0500 > From: Dmitri Pal > > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unable to Login until Trust is Repaired > Message-ID: <5463B83B.1040601 at redhat.com > > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 11/12/2014 08:44 AM, Jonathan Bradford wrote: > > This is my first post on the IPA mailing list. Hey guys :) > > I've successfully walked through the IdM Red Hat document on > > "Integrating with Active Directory Through Cross-Realm Kerberos > > Trusts" using separate DNS domains. I've reached the part where you > > test the trust using SSH via PuTTY, and I have noticed a problem. > > If I add a user in Active Directory (group mapping is on), the user > > cannot immediately SSH to an IPA host. In fact, it never allows me to > > login until I first login to a Windows machine with the account and > > then repair the trust via AD. > > To repair the trust, I have to go to AD Domains and Trusts > > > Properties > Trusts> and Validate the incoming and outgoing > > connections. When I do this, it gives me an error message about the > > RPC server not running, but if I proceed, it eventually tells me that > > the connection has been repaired. Only after doing this can I > > successfully SSH with a new user. > > Do you have any idea why this might be happening? I have followed Red > > Hat's documentation exactly, so I am not sure why I am having issues. > > If you have any thoughts or ideas, I would greatly appreciate them. > > Thanks! > > -Jonathan > > > > > HI Jonathan, > > I would leave to Alexander to drill down into the details when he is > back online tomorrow however if the trust is not validated then it is > not fully established the first time. Something when wrong and it would > be nice to look at the logs on the IPA and AD side to be able to > determine the cause. > Do you need to repair the trust for every single user or just once? > > What it is your AD domain topology? Are you establishing trust with the > primary domain controller? > What version of IPA and AD are you using? > > Thanks > Dmitri > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Nov 13 13:31:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Nov 2014 15:31:25 +0200 Subject: [Freeipa-users] Unable to Login until Trust is Repaired In-Reply-To: References: Message-ID: <20141113133125.GJ3493@redhat.com> On Wed, 12 Nov 2014, Jonathan Bradford wrote: >This is my first post on the IPA mailing list. Hey guys :) > >I've successfully walked through the IdM Red Hat document on "Integrating >with Active Directory Through Cross-Realm Kerberos Trusts" using separate >DNS domains. I've reached the part where you test the trust using SSH via >PuTTY, and I have noticed a problem. > >If I add a user in Active Directory (group mapping is on), the user cannot >immediately SSH to an IPA host. In fact, it never allows me to login until >I first login to a Windows machine with the account and then repair the >trust via AD. > >To repair the trust, I have to go to AD Domains and Trusts > Properties > >Trusts> and Validate the incoming and outgoing connections. When I do this, >it gives me an error message about the RPC server not running, but if I >proceed, it eventually tells me that the connection has been repaired. Only >after doing this can I successfully SSH with a new user. > >Do you have any idea why this might be happening? I have followed Red Hat's >documentation exactly, so I am not sure why I am having issues. If you have >any thoughts or ideas, I would greatly appreciate them. Thanks! We need to see debugging output to make decision on what is happening. >From your description I'd say you haven't had a trust properly configured and most likely either AD DCs don't see directly IPA masters or there is a domain/NetBIOS name conflicts in place. You can produce logs by following http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust For RHEL 6.x configuration use 'service' instead of 'systemctl' and separate actions for starting/stopping multiple services: service stop smb service stop winbind .. service start smb service start winbind .. You can then send logs to me directly. -- / Alexander Bokovoy From bradford.jonathan at gmail.com Thu Nov 13 13:37:02 2014 From: bradford.jonathan at gmail.com (Jonathan Bradford) Date: Thu, 13 Nov 2014 07:37:02 -0600 Subject: [Freeipa-users] Unable to Login until Trust is Repaired Message-ID: > 3.0 is a pretty old version, I mean a lot has changed in trust area between 3.0 and 3.3. > Any chance you can use that? > What distro do you use? I'm not sure if I can use a newer version. I'm using RHEL Server 6.5. I'm connected to a Satellite server, but it is a disconnected Satellite not allowed on the internet. Satellite updates have to be manually downloaded via .ISOs. The server has the most recent version of RHEL 6 updates on it. The .ISOs and versions are found on Red Hat's website here... https://www.redhat.com/wapps/sso/login.html?redirect=https%3A%2F%2Frhn.redhat.com%2Frhn%2Fsoftware%2Fchannel%2Fdownloads%2FDownload.do%3Fcid=18952 Date: Thu, 13 Nov 2014 08:27:28 -0500 From: Dmitri Pal To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Unable to Login until Trust is Repaired (Jonathan) Message-ID: <5464B1C0.1070709 at redhat.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" On 11/13/2014 08:15 AM, Jonathan Bradford wrote: > Dmitri: > Thanks for the reply. > > Do you need to repair the trust for every single user or just once? > Yes, I have to repair the trust for every new user added to Active > Directory who needs access to an IdM resource. Only once per user though. > > What it is your AD domain topology? > My AD topology is very simple at the moment because it is a test > environment. I currently have one domain controller with a domain of > venus.com . My IdM topology is very similar--one > IdM server with a domain of mercury.com . > > Are you establishing trust with the primary domain controller? > Yes. > > What version of IPA and AD are you using? > I'm using IPA v 3.0. I'm not sure of the current version of AD, but > I'm using it on Windows Server 2008 R2 SP1. 3.0 is a pretty old version, I mean a lot has changed in trust area between 3.0 and 3.3. Any chance you can use that? What distro do you use? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Nov 13 14:21:19 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Nov 2014 07:21:19 -0700 Subject: [Freeipa-users] Synchronization Agreements between FreeIPA and AD In-Reply-To: References: Message-ID: <5464BE5F.40100@redhat.com> On 11/13/2014 05:14 AM, ??????? ??????? wrote: > Hi Rich! > > I turned on the log and see the following records > > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): State: > start_backoff -> backoff > [13/Nov/2014:14:27:02 +0300] - acquire_replica, supplier RUV: > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - supplier: > {replicageneration} 5440f039000000030000 > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - supplier: > {replica 3 ldap://ipa.test-csbi-its.ru:389 > } 5440f039000100030000 > 5464956e000000030000 5464956e > [13/Nov/2014:14:27:02 +0300] - acquire_replica, consumer RUV: > [13/Nov/2014:14:27:02 +0300] - acquire_replica, consumer RUV = null > [13/Nov/2014:14:27:02 +0300] - acquire_replica, supplier RUV is newer > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Cancelling > linger on the connection > [13/Nov/2014:14:27:02 +0300] - _csngen_adjust_local_time: gen state > before 546495820001:1415878018:0:0 > [13/Nov/2014:14:27:02 +0300] - _csngen_adjust_local_time: gen state > after 546495860000:1415878022:0:0 > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): State: > backoff -> sending_updates > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Replica > has no update vector. It has never been initialized. > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): Beginning > linger on the connection > [13/Nov/2014:14:27:02 +0300] NSMMReplicationPlugin - > agmt="cn=meTocsbi-it-dc01.csbigroup.ru > " (csbi-it-dc01:389): State: > sending_updates -> start_backoff > There is no windows sync trace activity here. You have to first enable the replication log level, then do something that will trigger windows sync activity. > Best regards, Valeriy > > > > On 10/29/2014 03:19 AM, ??????? ??????? wrote: >> Yes Dmitri, ldapsearch works good: >> >> [root ipa ~]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-TEST-CSBI-ITS-RU/ >> ldapsearch -xLLL -ZZ -h csbi-it-dc01.csbigroup.ru >> -D >> "cn=ipa-test,cn=users,dc=csbigroup,dc=ru" -w "ttttttttt" -s base -b >> "cn=users,dc=csbigroup,dc=ru" >> dn: cn=users,dc=csbigroup,dc=ru >> objectClass: top >> objectClass: container >> cn: Users >> description: Default container for upgraded user accounts >> distinguishedName: CN=Users,DC=csbigroup,DC=ru >> instanceType: 4 >> ... >> ... >> > > Ok. Now try to do a windows sync with the dirsrv replication error > log level - http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting > > Then we can take a look at the detailed errors. > >> >> ? ?????????, ??????? ??????? >> >> 2014-10-23 16:19 GMT+04:00 ??????? ??????? > >: >> >> Hello! >> >> I tryed to configure synchronization between FreeIPA and Windows >> AD 2012. In the thirst time accounts from AD synchronization >> properly but next schedule after 5 min is not work and in error >> log I see the following errors: >> >> # tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors >> [23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): >> Replica has no update vector. It has never been initialized. >> [23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): >> Replica has no update vector. It has never been initialized. >> [23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - >> agmt="cn=meTocsbi-it-dc01.csbigroup.ru >> " (csbi-it-dc01:389): >> Replica has no update vector. It has never been initialized. >> >> Thirst synchronization out >> >> Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to >> certificate database for ipa.test-csbi-its.ru >> >> ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru >> The user for the Windows PassSync service is >> uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru >> Windows PassSync entry exists, not resetting password >> ipa: INFO: Added new sync agreement, waiting for it to become >> ready . . . >> ipa: INFO: Replication Update in progress: FALSE: status: 0 >> Replica acquired successfully: Incremental update started: start: >> 0: end: 0 >> ipa: INFO: Agreement is ready, starting replication . . . >> Starting replication, please wait until this has completed. >> Update in progress, 13 seconds elapsed >> [ipa.test-csbi-its.ru ] reports: >> Update failed! Status: [-1 Total update abortedLDAP error: Can't >> contact LDAP server] >> >> Failed to start replication >> >> >> >> FreeIPA server version 3.3.3 >> OS version Centos 7 >> AD Domain 2012 >> >> Can you help me to resolve this problem? >> >> Best regards, Valeriy >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Nov 13 14:26:27 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Nov 2014 07:26:27 -0700 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> <54636BB8.3080700@redhat.com> Message-ID: <5464BF93.7040903@redhat.com> On 11/13/2014 03:02 AM, Walter van Lille wrote: > Thanks Rich, I have installed the packages and run gdb again. > Hopefully the attached file is more useful. The symbols are there. However, the server is almost completely idle - no hangs, no deadlocks, no waiting on I/O. You must catch dirsrv while it is hung. You might want to run that gdb script every few seconds during the time it appears to be hung. > > On Wed, Nov 12, 2014 at 4:16 PM, Rich Megginson > wrote: > > On 11/12/2014 05:42 AM, Walter van Lille wrote: >> Thanks again for the assistance guys. I have saved two files and >> included it here. Hope it tells you more than it does me. > > These stack traces contain no useful symbols. > > Please read > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > to find out how to install the correct debuginfo packages on your > system. For IPA you will also need debuginfo packages for ipa and > slapi-nis > > If debuginfo-install is not working, see > https://www.centos.org/forums/viewtopic.php?t=1710 > > If you simply cannot figure out how to install the debuginfo > packages, please email me with the following information: > > $ rpm -q ipa-server slapi-nis 389-ds-base openldap db4 nss nspr glibc > > and I will make them available to you > > NOTE: With debuginfo packages, the version of the debuginfo > package _must exactly match_ the version of the associated package > e.g. for 389-ds-base.x86_64 1.2.11.15-34.el6_5 you must have > 389-ds-base-debuginfo.x86_64 1.2.11.15-34.el6_5 > > If the versions do not match exactly, you will not get the symbols. > >> >> Regards, >> >> Wallter >> >> On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson >> > wrote: >> >> On 11/11/2014 10:37 AM, Martin Basti wrote: >>> On 11/11/14 15:58, Rich Megginson wrote: >>>> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >>>>> >>>>> On 11/11/2014 02:14 PM, Martin Basti wrote: >>>>>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >>>>> hmm, it says limit is 2097152, so it already has the new >>>>> setting, but the error message says the packet is 800MB* >>>>> * >>>> >>>> *Right. That usually means the server was expecting an >>>> encrypted SASL buffer from the client, but instead the >>>> client thinks SASL encryption negotiation failed and just >>>> sent a plain LDAP buffer. What version of 389-ds-base are >>>> you using? rpm -q 389-ds-base >>>> >>>> https://fedorahosted.org/389/ticket/47416 >>>> >>>> So, DO NOT increase your sasl io buffer size - it will not >>>> fix the problem, and it will leave you open to DoS attacks. >>>> * >>> >>> He is using >>> >>> CentOS release 6.5 (Final) >>> 389-ds-base.x86_64 1.2.11.15-34.el6_5 >> >> >> Ignore the "SASL encrypted packet length exceeds maximum >> allowed limit" error. All it means is the client has some >> error and is canceling the connection. >> >> The bugzilla associated with *47416 >> is targeted for >> RHEL 7.1. The problem is that we were never able to figure >> out what error the client was getting that caused the client >> to stop establishing the *SASL encryption, and the original >> customer who reported the problem dropped the case - >> everything just started working, no further errors. Note >> that 47416 doesn't really fix the problem or address the root >> cause - the root cause is some error on the client side that >> causes it to stop doing encrypted SASL I/O and send an LDAP >> unbind request. >> >> Let's get back to the actual problem - what is the actual >> problem? The ldap server is hanging or unresponsive? If so, >> then see >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. >> Let's get some dirsrv stack traces during the period of time >> when it appears to be unresponsive. >> >> >>> >>>> * >>>> * >>>>> ** >>>>>> >>>>>> On 11/11/14 13:13, Walter van Lille wrote: >>>>>>> I've just cleaned out a ton of slapd_poll timed out >>>>>>> messages from the output and changed the names to >>>>>>> protect the innocent, :-) >>>>>>> Here is the output as requested: >>>>>>> >>>>>>> >>>>>>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet >>>>>>> length exceeds maximum allowed limit (length=805565, >>>>>>> limit=2097152). Change the nsslapd-maxsasliosize >>>>>>> attribute in cn=config to increase limit.* >>>>>>> * >>>>>>> * >>>>>>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>>>>>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot >>>>>>> enable SASL security on connection in CLOSING state* >>>>>>> *[10/Nov/2014:14:45:19 +0200] - Error: could not >>>>>>> add/remove IO layers from connection* >>>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - >>>>>>> signaling operation threads* >>>>>>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - >>>>>>> waiting for 30 threads to terminate* >>>>>>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - >>>>>>> closing down internal subsystems and plugins* >>>>>>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database >>>>>>> threads to stop* >>>>>>> *[11/Nov/2014:13:14:13 +0200] - All database threads now >>>>>>> stopped* >>>>>>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>>>>>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>>>>>> B2014.219.179 starting up* >>>>>>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - >>>>>>> warning: no entries set up under cn=computers, >>>>>>> cn=compat,dc=sample,dc=example* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no >>>>>>> CoS Templates found, which should be added before the >>>>>>> CoS Definition.* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition >>>>>>> cn=Password Policy,cn=accounts,dc=sample,dc=example--no >>>>>>> CoS Templates found, which should be added before the >>>>>>> CoS Definition.* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - slapd started. >>>>>>> Listening on All Interfaces port 389 for LDAP requests* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on All >>>>>>> Interfaces port 636 for LDAPS requests* >>>>>>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>>>>>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>>>>>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti >>>>>>> > wrote: >>>>>>> >>>>>>> IMHO It's DS bug, can you share DS error log? >>>>>>> pspacek CCed to examine named logs. >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>>> >>>>>>> On 11/11/14 12:13, Walter van Lille wrote: >>>>>>>> Hi Martin, thanks for the reply. >>>>>>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>>>>>> The server doesn't have journalctl installed but I >>>>>>>> have the outputs from the messages and named.run >>>>>>>> files that I included here: >>>>>>>> >>>>>>>> Messages: >>>>>>>> >>>>>>>> *Nov 11 12:30:13 freeipa named[1481]: error >>>>>>>> (network unreachable) resolving >>>>>>>> 'example.example.com.10.123.123.123/A/IN': >>>>>>>> 2001:500:2f::f#53* >>>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query >>>>>>>> timed out. Try to adjust "timeout" parameter* >>>>>>>> >>>>>>>> Named.run: >>>>>>>> >>>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>>> 'example.example/IN': AXFR-style IXFR started* >>>>>>>> *client 10.123.123.123#42639: transfer of >>>>>>>> ''example.example/IN': AXFR-style IXFR ended* >>>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR >>>>>>>> started* >>>>>>>> *client 10.123.123.123#46912: transfer of >>>>>>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR >>>>>>>> ended* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> *LDAP query timed out. Try to adjust "timeout" >>>>>>>> parameter* >>>>>>>> >>>>>>>> I just replaced the IPs and the actual names with >>>>>>>> something more generic. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Walter >>>>>>>> >>>>>>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti >>>>>>>> > wrote: >>>>>>>> >>>>>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I need some assistance please. >>>>>>>>> I've taken over an IPA server to manage a few >>>>>>>>> months ago, and it was working fine until >>>>>>>>> recently when it started acting up seemingly >>>>>>>>> off its own accord. >>>>>>>>> When I do an ipactl status it basically gives >>>>>>>>> an output as shown below: >>>>>>>>> >>>>>>>>> >>>>>>>>> *Directory Service: RUNNING >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong >>>>>>>>> pause... (To the tune of 7 minutes sometimes)* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *KDC Service: RUNNING* >>>>>>>>> *KPASSWD Service: RUNNING* >>>>>>>>> *DNS Service: RUNNING* >>>>>>>>> *MEMCACHE Service: RUNNING* >>>>>>>>> *HTTP Service: RUNNING* >>>>>>>>> *CA Service: RUNNING* >>>>>>>>> *ADTRUST Service: RUNNING* >>>>>>>>> *EXTID Service: RUNNING* >>>>>>>>> >>>>>>>>> Running top showed that ns-slapd was munching >>>>>>>>> almost all my resources, but I got that fixed >>>>>>>>> by upping the cache. Unfortunately this did >>>>>>>>> not correct the issue and it still reacts in >>>>>>>>> the same fashion, although the resources have >>>>>>>>> been freed up now. >>>>>>>>> I've noticed that when I run dig on either the >>>>>>>>> local server or a remote machine that the >>>>>>>>> query basically just times out as shown here: >>>>>>>>> >>>>>>>>> *dig freeipa.myexample.sample* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *; <<>> DiG >>>>>>>>> 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>>>>>> freeipa.myexample.sample* >>>>>>>>> *;; global options: +cmd* >>>>>>>>> *;; connection timed out; no servers could be >>>>>>>>> reached* >>>>>>>>> >>>>>>>>> When the KDC service fails to start, then name >>>>>>>>> lookups seem OK, but authentication fails. >>>>>>>>> otherwise it's dead in the water. >>>>>>>>> >>>>>>>>> This also happens: >>>>>>>>> >>>>>>>>> *sudo ipactl status* >>>>>>>>> *Directory Service: RUNNING* >>>>>>>>> *Unknown error when retrieving list of >>>>>>>>> services from LDAP:* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> My software setup is as follows: >>>>>>>>> >>>>>>>>> *CentOS release 6.5 (Final) >>>>>>>>> * >>>>>>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 >>>>>>>>> * >>>>>>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 >>>>>>>>> * >>>>>>>>> *bind-dyndb-ldap.x86_64* >>>>>>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>>>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>>>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>>>>>> *samba4-winbind.x86_64* >>>>>>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue >>>>>>>>> Sep 9 21:36:05 UTC 2014 x86_64 x86_64 x86_64 >>>>>>>>> GNU/Linux >>>>>>>>> * >>>>>>>>> >>>>>>>>> It's not a permanent situation as it sometimes >>>>>>>>> runs 100% for a while, but 80% of the time it >>>>>>>>> is unusable. If anybody can assist me, please >>>>>>>>> be so kind. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Walter >>>>>>>>> >>>>>>>> Hello please which version of bind-dyndb-ldap >>>>>>>> do you use? >>>>>>>> I had similar issue with bind-dyndb-ldap, but >>>>>>>> it was development version, I'm not sure if >>>>>>>> this is your case. >>>>>>>> When named was failing, dirserv was really slow. >>>>>>>> >>>>>>>> Can you send journalctl -b -u named log when >>>>>>>> dig doesn't work?? >>>>>>>> >>>>>>>> -- >>>>>>>> Martin Basti >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Martin Basti >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >> >> >> -- >> 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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 13 16:18:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Nov 2014 11:18:48 -0500 Subject: [Freeipa-users] Unable to Login until Trust is Repaired In-Reply-To: References: Message-ID: <5464D9E8.6080607@redhat.com> On 11/13/2014 08:37 AM, Jonathan Bradford wrote: > > 3.0 is a pretty old version, I mean a lot has changed in trust area > between 3.0 and 3.3. > > Any chance you can use that? > > What distro do you use? > I'm not sure if I can use a newer version. I'm using RHEL Server 6.5. > I'm connected to a Satellite server, but it is a disconnected > Satellite not allowed on the internet. Satellite updates have to be > manually downloaded via .ISOs. The server has the most recent version > of RHEL 6 updates on it. The .ISOs and versions are found on Red Hat's > website here... > https://www.redhat.com/wapps/sso/login.html?redirect=https%3A%2F%2Frhn.redhat.com%2Frhn%2Fsoftware%2Fchannel%2Fdownloads%2FDownload.do%3Fcid=18952 3.3 is RHEL 7.0. I think there is an image: RHEL 7 (x86_64) + EUS + RHN Tools + Optional (Base 2014-06-24) > Date: Thu, 13 Nov 2014 08:27:28 -0500 > From: Dmitri Pal > > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Unable to Login until Trust is Repaired > (Jonathan) > Message-ID: <5464B1C0.1070709 at redhat.com > > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 11/13/2014 08:15 AM, Jonathan Bradford wrote: > > Dmitri: > > Thanks for the reply. > > > Do you need to repair the trust for every single user or just once? > > Yes, I have to repair the trust for every new user added to Active > > Directory who needs access to an IdM resource. Only once per user > though. > > > What it is your AD domain topology? > > My AD topology is very simple at the moment because it is a test > > environment. I currently have one domain controller with a domain of > > venus.com >. My IdM topology is very similar--one > > IdM server with a domain of mercury.com > >. > > > Are you establishing trust with the primary domain controller? > > Yes. > > > What version of IPA and AD are you using? > > I'm using IPA v 3.0. I'm not sure of the current version of AD, but > > I'm using it on Windows Server 2008 R2 SP1. > > 3.0 is a pretty old version, I mean a lot has changed in trust area > between 3.0 and 3.3. > Any chance you can use that? > > What distro do you use? > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Fri Nov 14 07:02:33 2014 From: techpkiuser at gmail.com (pki tech) Date: Fri, 14 Nov 2014 12:32:33 +0530 Subject: [Freeipa-users] Urgent Help Needed - CA subsystem certificate renewal Message-ID: Dear All, In our Issuing CA, all the subsystem certificates are expired except the caSigningCert. I can generate the new certificate requests via certutil, but how can i get them signed? your swift response is appreciated. Regards, Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 14 10:20:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Nov 2014 11:20:17 +0100 Subject: [Freeipa-users] Urgent Help Needed - CA subsystem certificate renewal In-Reply-To: References: Message-ID: <5465D761.8080407@redhat.com> On 11/14/2014 08:02 AM, pki tech wrote: > Dear All, > > In our Issuing CA, all the subsystem certificates are expired except the > caSigningCert. > > I can generate the new certificate requests via certutil, but how can i get > them signed? > > your swift response is appreciated. > > Regards, > Kamal What IPA version did you use? We have a related howto article on FreeIPA.org wiki with instructions what to do when PKI subsystem certificate expire: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal Also CCing Jan who owns the PKI knowledge. Martin From andreas.ladanyi at kit.edu Fri Nov 14 10:39:48 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Fri, 14 Nov 2014 11:39:48 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <20141113093553.GE3493@redhat.com> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> Message-ID: <5465DBF4.50400@kit.edu> > [root at cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test > --------------------------------------- > Added host "afs-cellname.ipacloud.test" > --------------------------------------- > Host name: afs-cellname.ipacloud.test > Principal name: host/afs-cellname.ipacloud.test at IPACLOUD.TEST > Password: False > Keytab: False > Managed by: afs-cellname.ipacloud.test ok, i have done a "ipa host-add --force afscellname (in my case equal to the domainname)" > [root at cc21 ~]# ipa service-add --force afs/afs-cellname > ---------------------------------------------- > Added service "afs/afs-cellname at IPACLOUD.TEST" > ---------------------------------------------- > Principal: afs/afs-cellname at IPACLOUD.TEST > Managed by: afs-cellname.ipacloud.test > [root at cc21 ~]# ipa service-show afs/afs-cellname > Principal: afs/afs-cellname at IPACLOUD.TEST > Keytab: False > Managed by: afs-cellname.ipacloud.test > [root at cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname -k > /tmp/afs.keytab Keytab successfully retrieved and stored in: > /tmp/afs.keytab ok, i have done a "ipa service-add --force afs/cellname (in my case equal to the domainname)" > > As you can see there is no problem at all -- all you need is to have a > host entry with the same name as afs-cellname. Note that the host > afs-cellname doesn't even need to exist in DNS. > > However, your primary problem would be in a different area. You'll need > to enable weak crypto at KDC server, Kerberos clients, and LDAP servers. > > krb5.conf (on both IPA masters and clients): > [libdefaults] > allow_weak_crypto = true done. > > /var/kerberos/krb5kdc/kdc.conf (on IPA masters): > [realms] > IPACLOUD.TEST = { > supported_enctypes = aes256-cts-hmac-sha1-96:normal > aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal > arcfour-hmac-md5:normal des-cbc-crc:v4 > } > done > Finally, you need to modify > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > and add des-cbc-crc:v4 to supported Kerberos encryption types with > krbSupportedEncSaltTypes > attribute. You have to use ldapmodify as cn=Directory Manager for that > as we don't allow admins to modify these entries directly. i used the jexplorer to modify the entries. > > A simplified approach would be to use ipa-ldap-updater with your own > update file (which should have a name like -.update where > is something between 01 and 90): > > [root at cc21 ~]# cat 20-weak-enctypes.update dn: > cn=$REALM,cn=kerberos,$SUFFIX > add: krbSupportedEncSaltTypes: des-cbc-crc:v4 > > [root at cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory > Manager password: > Parsing update file './20-weak-enctypes.update' > Updating existing entry: > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > Done > The ipa-ldap-updater command was successful > > Only after that you'll get ipa-getkeytab to generate weaker encryption > type-based keys. ok. getprinc of the afs/cellname at REALM principal says: Key: vno 1, aes256-cts-hmac-sha1-96, no salt Key: vno 1, aes128-cts-hmac-sha1-96, no salt Key: vno 1, des3-cbc-sha1, no salt Key: vno 1, arcfour-hmac, no salt Key: vno 1, camellia128-cts-cmac, no salt Key: vno 1, camellia256-cts-cmac, no salt Key: vno 1, des-cbc-crc, no salt It looks like the single-des key was created. If i ask for a tgt and a afs/cellname at REALM tgs ticket with kinit and aklog (from OpenAFS) i only get an AES256 key, but none single-DES ticket. >From the client pc: kvno -e des-cbc-crc afs/cellname principal kvno: KDC has no support for encryption type while getting credentials for afs/cellname at REALM kvno -e aes256-cts afs/cellname principal afs/cellname at REALM: kvno = 1 > However, we have a problem in FreeIPA 4.x that an > attempt to force only a specific encryption type in ipa-getkeytab is > ignored and instead only enctypes from krbDefaultEncSaltTypes attribute > are generated. This bug is tracked with > https://fedorahosted.org/freeipa/ticket/4718 i use the FreeIPA 3.3.5 with Fedora on the single IPA Master. cheers, Andreas From techpkiuser at gmail.com Fri Nov 14 10:56:23 2014 From: techpkiuser at gmail.com (Kamal Perera) Date: Fri, 14 Nov 2014 16:26:23 +0530 Subject: [Freeipa-users] Urgent Help Needed - CA subsystem certificate renewal In-Reply-To: <5465D761.8080407@redhat.com> References: <5465D761.8080407@redhat.com> Message-ID: Hi Martin, Thanks for the reply. its FreeIPA 3. Actually my issue was, all my subsystem certificates were expired two days back. So it wasnt possible to get the requests signed and approved by the CA as the web interface in inaccessible. But after several attempts, I got it done by changing the date back to a valid time. Now i have revert back and everything is fine except this. now the RA and OCSPs are not communicating with the CA. I guess its because the CA's subsystem certificate is expired. So do i have to reissue all the subsystem certificates in RA and OCSP? Any thoughts? Thanks On Fri, Nov 14, 2014 at 3:50 PM, Martin Kosek wrote: > On 11/14/2014 08:02 AM, pki tech wrote: > >> Dear All, >> >> In our Issuing CA, all the subsystem certificates are expired except the >> caSigningCert. >> >> I can generate the new certificate requests via certutil, but how can i >> get >> them signed? >> >> your swift response is appreciated. >> >> Regards, >> Kamal >> > > What IPA version did you use? We have a related howto article on > FreeIPA.org wiki with instructions what to do when PKI subsystem > certificate expire: > > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > > Also CCing Jan who owns the PKI knowledge. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.van.lille at gmail.com Fri Nov 14 11:16:40 2014 From: walter.van.lille at gmail.com (Walter van Lille) Date: Fri, 14 Nov 2014 13:16:40 +0200 Subject: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations In-Reply-To: <54648776.3090801@redhat.com> References: <545B8D05.6030705@redhat.com> <5461F0C7.4010208@redhat.com> <54620BA9.7070705@redhat.com> <54620D12.4050809@redhat.com> <5462240E.7000401@redhat.com> <54624949.6030200@redhat.com> <54624F5A.8020304@redhat.com> <54636BB8.3080700@redhat.com> <54648776.3090801@redhat.com> Message-ID: Roughly 128 clients.. But when the services start going gaa-gaa it also causes time-outs with the naming service running on the same server. I may be wrong, but wouldn't that basically kill any chance of a client connecting to the server anyway? I'm just lucky that the clients aren't really there for general usage, so the only times that users actually try to log in is when it is support staff that needs to check or restart a pretty static, stable service. I just want to add that the server is not hung when doing an ipactl status and the KDC service is not started as below, so are we barking up the right tree looking at the DS service? (PS, the KDC service was not manually stopped by me. *sudo ipactl status* *Directory Service: RUNNING* *KDC Service: STOPPED* *KPASSWD Service: RUNNING* *DNS Service: RUNNING* *MEMCACHE Service: RUNNING* *HTTP Service: RUNNING* *CA Service: RUNNING* *ADTRUST Service: RUNNING* *EXTID Service: RUNNING* On Thu, Nov 13, 2014 at 12:27 PM, Ludwig Krispenz wrote: > Hmm, the symbols are there now, but all threads are idle, DS is just > waiting on work to do. Which client do you expect to connect to DS, maybe > you need to debug this client. > > > On 11/13/2014 11:02 AM, Walter van Lille wrote: > > Thanks Rich, I have installed the packages and run gdb again. Hopefully > the attached file is more useful. > > On Wed, Nov 12, 2014 at 4:16 PM, Rich Megginson > wrote: > >> On 11/12/2014 05:42 AM, Walter van Lille wrote: >> >> Thanks again for the assistance guys. I have saved two files and included >> it here. Hope it tells you more than it does me. >> >> >> These stack traces contain no useful symbols. >> >> Please read >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to find >> out how to install the correct debuginfo packages on your system. For IPA >> you will also need debuginfo packages for ipa and slapi-nis >> >> If debuginfo-install is not working, see >> https://www.centos.org/forums/viewtopic.php?t=1710 >> >> If you simply cannot figure out how to install the debuginfo packages, >> please email me with the following information: >> >> $ rpm -q ipa-server slapi-nis 389-ds-base openldap db4 nss nspr glibc >> >> and I will make them available to you >> >> NOTE: With debuginfo packages, the version of the debuginfo package _must >> exactly match_ the version of the associated package e.g. for 389-ds-base.x86_64 >> 1.2.11.15-34.el6_5 you must have >> 389-ds-base-debuginfo.x86_64 1.2.11.15-34.el6_5 >> >> If the versions do not match exactly, you will not get the symbols. >> >> >> Regards, >> >> Wallter >> >> On Tue, Nov 11, 2014 at 8:03 PM, Rich Megginson >> wrote: >> >>> On 11/11/2014 10:37 AM, Martin Basti wrote: >>> >>> On 11/11/14 15:58, Rich Megginson wrote: >>> >>> On 11/11/2014 06:20 AM, Ludwig Krispenz wrote: >>> >>> >>> On 11/11/2014 02:14 PM, Martin Basti wrote: >>> >>> Ludiwg (CCed) this seems like old (fixed?) DS bug. >>> >>> hmm, it says limit is 2097152, so it already has the new setting, but >>> the error message says the packet is 800MB >>> >>> >>> >>> >>> >>> >>> >>> *Right. That usually means the server was expecting an encrypted SASL >>> buffer from the client, but instead the client thinks SASL encryption >>> negotiation failed and just sent a plain LDAP buffer. What version of >>> 389-ds-base are you using? rpm -q 389-ds-base >>> https://fedorahosted.org/389/ticket/47416 >>> So, DO NOT increase your sasl >>> io buffer size - it will not fix the problem, and it will leave you open to >>> DoS attacks. * >>> >>> >>> He is using >>> >>> CentOS release 6.5 (Final) >>> 389-ds-base.x86_64 1.2.11.15-34.el6_5 >>> >>> >>> >>> Ignore the "SASL encrypted packet length exceeds maximum allowed limit" >>> error. All it means is the client has some error and is canceling the >>> connection. >>> >>> The bugzilla associated with *47416 >>> is targeted for RHEL 7.1. The >>> problem is that we were never able to figure out what error the client was >>> getting that caused the client to stop establishing the *SASL >>> encryption, and the original customer who reported the problem dropped the >>> case - everything just started working, no further errors. Note that 47416 >>> doesn't really fix the problem or address the root cause - the root cause >>> is some error on the client side that causes it to stop doing encrypted >>> SASL I/O and send an LDAP unbind request. >>> >>> Let's get back to the actual problem - what is the actual problem? The >>> ldap server is hanging or unresponsive? If so, then see >>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. Let's >>> get some dirsrv stack traces during the period of time when it appears to >>> be unresponsive. >>> >>> >>> >>> >>> >>> On 11/11/14 13:13, Walter van Lille wrote: >>> >>> I've just cleaned out a ton of slapd_poll timed out messages from the >>> output and changed the names to protect the innocent, :-) >>> Here is the output as requested: >>> >>> >>> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds >>> maximum allowed limit (length=805565, limit=2097152). Change the >>> nsslapd-maxsasliosize attribute in cn=config to increase limit.* >>> >>> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out* >>> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL >>> security on connection in CLOSING state* >>> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers >>> from connection* >>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling >>> operation threads* >>> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 >>> threads to terminate* >>> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down >>> internal subsystems and plugins* >>> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop* >>> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped* >>> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.* >>> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 >>> B2014.219.179 starting up* >>> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries >>> set up under cn=computers, cn=compat,dc=sample,dc=example* >>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which >>> should be added before the CoS Definition.* >>> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which >>> should be added before the CoS Definition.* >>> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests* >>> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for >>> LDAPS requests* >>> *[11/Nov/2014:13:26:36 +0200] - Listening on >>> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests* >>> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out* >>> >>> >>> >>> >>> >>> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti wrote: >>> >>>> IMHO It's DS bug, can you share DS error log? >>>> pspacek CCed to examine named logs. >>>> >>>> Martin^2 >>>> >>>> >>>> On 11/11/14 12:13, Walter van Lille wrote: >>>> >>>> Hi Martin, thanks for the reply. >>>> My version: bind-dyndb-ldap-2.3-5.el6.x86_64 >>>> The server doesn't have journalctl installed but I have the outputs >>>> from the messages and named.run files that I included here: >>>> >>>> Messages: >>>> >>>> *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) >>>> resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53* >>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to >>>> adjust "timeout" parameter* >>>> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to >>>> adjust "timeout" parameter* >>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to >>>> adjust "timeout" parameter* >>>> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to >>>> adjust "timeout" parameter* >>>> >>>> Named.run: >>>> >>>> *client 10.123.123.123#42639: transfer of 'example.example/IN': >>>> AXFR-style IXFR started* >>>> *client 10.123.123.123#42639: transfer of ''example.example/IN': >>>> AXFR-style IXFR ended* >>>> *client 10.123.123.123#46912: transfer of >>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started* >>>> *client 10.123.123.123#46912: transfer of >>>> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> *LDAP query timed out. Try to adjust "timeout" parameter* >>>> >>>> I just replaced the IPs and the actual names with something more >>>> generic. >>>> >>>> Regards, >>>> >>>> Walter >>>> >>>> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti wrote: >>>> >>>>> On 06/11/14 14:58, Walter van Lille wrote: >>>>> >>>>> Hi, >>>>> >>>>> I need some assistance please. >>>>> I've taken over an IPA server to manage a few months ago, and it was >>>>> working fine until recently when it started acting up seemingly off its own >>>>> accord. >>>>> When I do an ipactl status it basically gives an output as shown below: >>>>> >>>>> >>>>> >>>>> *Directory Service: RUNNING * >>>>> >>>>> *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To >>>>> the tune of 7 minutes sometimes)* >>>>> >>>>> *KDC Service: RUNNING* >>>>> *KPASSWD Service: RUNNING* >>>>> *DNS Service: RUNNING* >>>>> *MEMCACHE Service: RUNNING* >>>>> *HTTP Service: RUNNING* >>>>> *CA Service: RUNNING* >>>>> *ADTRUST Service: RUNNING* >>>>> *EXTID Service: RUNNING* >>>>> >>>>> Running top showed that ns-slapd was munching almost all my >>>>> resources, but I got that fixed by upping the cache. Unfortunately this did >>>>> not correct the issue and it still reacts in the same fashion, although the >>>>> resources have been freed up now. >>>>> I've noticed that when I run dig on either the local server or a >>>>> remote machine that the query basically just times out as shown here: >>>>> >>>>> *dig freeipa.myexample.sample* >>>>> >>>>> *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> >>>>> freeipa.myexample.sample* >>>>> *;; global options: +cmd* >>>>> *;; connection timed out; no servers could be reached* >>>>> >>>>> When the KDC service fails to start, then name lookups seem OK, but >>>>> authentication fails. otherwise it's dead in the water. >>>>> >>>>> This also happens: >>>>> >>>>> *sudo ipactl status* >>>>> *Directory Service: RUNNING* >>>>> *Unknown error when retrieving list of services from LDAP:* >>>>> >>>>> My software setup is as follows: >>>>> >>>>> >>>>> *CentOS release 6.5 (Final) * >>>>> >>>>> *389-ds-base.x86_64 1.2.11.15-34.el6_5 * >>>>> >>>>> *bind.x86_64 32:9.8.2-0.23.rc1.el6_5.1 * >>>>> *bind-dyndb-ldap.x86_64* >>>>> *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>> *bind-utils.x86_64 32:9.8.2-0.23.rc1.el6_5.1* >>>>> *rpcbind.x86_64 0.2.0-11.el6 >>>>> @anaconda-CentOS-201311291202.x86_64/6.5* >>>>> *samba4-winbind.x86_64* >>>>> >>>>> *krb5-server.x86_64 1.10.3-15.el6_5.1 * >>>>> >>>>> >>>>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014 >>>>> x86_64 x86_64 x86_64 GNU/Linux * >>>>> >>>>> It's not a permanent situation as it sometimes runs 100% for a >>>>> while, but 80% of the time it is unusable. If anybody can assist me, please >>>>> be so kind. >>>>> >>>>> Regards, >>>>> >>>>> Walter >>>>> >>>>> Hello please which version of bind-dyndb-ldap do you use? >>>>> I had similar issue with bind-dyndb-ldap, but it was development >>>>> version, I'm not sure if this is your case. >>>>> When named was failing, dirserv was really slow. >>>>> >>>>> Can you send journalctl -b -u named log when dig doesn't work?? >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> >>> >>> -- >>> Martin Basti >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Martin Basti >>> >>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 14 11:28:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Nov 2014 12:28:09 +0100 Subject: [Freeipa-users] Urgent Help Needed - CA subsystem certificate renewal In-Reply-To: References: <5465D761.8080407@redhat.com> Message-ID: <5465E749.9000805@redhat.com> You need to get all certificates in # getcert list renewed. With FreeIPA 3.0+ the certificates should be already properly tracked, AFAIR. Was the uid=ipara,ou=People,o=ipaca entry (as described in http://www.freeipa.org/page/IPA_2x_Certificate_Renewal) properly updated with a serial pointing to the new certificate? Maybe this is the reason why old RA certificate is loaded. If you are using RHEL/CentOS, I would also recommend updating ipa, certmonger and selinux-policy to the 6.6 version is there were several related fixes. Martin On 11/14/2014 11:56 AM, Kamal Perera wrote: > Hi Martin, > > Thanks for the reply. > > its FreeIPA 3. > > Actually my issue was, all my subsystem certificates were expired two days > back. So it wasnt possible to get the requests signed and approved by the CA as > the web interface in inaccessible. > > But after several attempts, I got it done by changing the date back to a valid > time. Now i have revert back and everything is fine except this. > > now the RA and OCSPs are not communicating with the CA. > > I guess its because the CA's subsystem certificate is expired. So do i have to > reissue all the subsystem certificates in RA and OCSP? > > Any thoughts? > > Thanks > > On Fri, Nov 14, 2014 at 3:50 PM, Martin Kosek > wrote: > > On 11/14/2014 08:02 AM, pki tech wrote: > > Dear All, > > In our Issuing CA, all the subsystem certificates are expired except the > caSigningCert. > > I can generate the new certificate requests via certutil, but how can i get > them signed? > > your swift response is appreciated. > > Regards, > Kamal > > > What IPA version did you use? We have a related howto article on > FreeIPA.org wiki with instructions what to do when PKI subsystem > certificate expire: > > http://www.freeipa.org/page/__IPA_2x_Certificate_Renewal > > > Also CCing Jan who owns the PKI knowledge. > > Martin > > From darren.poulson at genesys.com Fri Nov 14 12:10:59 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Fri, 14 Nov 2014 12:10:59 +0000 Subject: [Freeipa-users] Group membership not populated Message-ID: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> Hi, I'm currently having an issue where if I log in as a user on a freshly rebooted machine, their group membership is not populated, so things like sudo do not work properly. If I do a getent group , log out and log back in again, then it works properly. for example -sh-4.1$ groups dpoulson dpoulson : dpoulson ops_admins helpdesk -sh-4.1$ getent group ops_users ops_users:*:50130:dpoulson,anotheruser,andanother,etc -sh-4.1$ groups dpoulson dpoulson : dpoulson ops_admins helpdesk ops_users -sh-4.1$ groups dpoulson ops_admins helpdesk -sh-4.1$ groups dpoulson helpdesk ops_admins ops_users (the user is actually meant to be a member of 6 groups) Client and server machines are all fresh installs of CentOS 6.6, running: ipa-server-3.0.0-42.el6.centos.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 All config files I've checked are identical (/etc/nsswitch.conf, /etc/sssd/sssd.conf, /etc/sudo-ldap.conf) - any more I should check? Tho that being said, they were all kickstarted from the same image with the same chef recipes. /etc/sssd/sssd.conf: [domain/bur.us.genops] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = bur.us.genops id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = pwm1-01.bur.us.genops chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, freeipa1-01.bur.us.genops ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 8 [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = bur.us.genops [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus sudoers: files sss Any ideas where to start looking? Thanks, Darren. From jhrozek at redhat.com Fri Nov 14 14:56:15 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 14 Nov 2014 15:56:15 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141114145615.GC12319@hendrix.brq.redhat.com> On Fri, Nov 14, 2014 at 12:10:59PM +0000, Darren Poulson wrote: > Hi, > > I'm currently having an issue where if I log in as a user on a freshly rebooted machine, their group membership is not populated, so things like sudo do not work properly. If I do a getent group , log out and log back in again, then it works properly. > > for example > > -sh-4.1$ groups dpoulson > dpoulson : dpoulson ops_admins helpdesk > -sh-4.1$ getent group ops_users > ops_users:*:50130:dpoulson,anotheruser,andanother,etc Is ops_users an IPA group that dpoulsen is a member of (or maybe some AD trust group or a local UNIX group)? > -sh-4.1$ groups dpoulson > dpoulson : dpoulson ops_admins helpdesk ops_users > -sh-4.1$ groups > dpoulson ops_admins helpdesk > > > > -sh-4.1$ groups > dpoulson helpdesk ops_admins ops_users Taking the missing ops_users group out of the picture, this is expected, memberships are set on login only. > > (the user is actually meant to be a member of 6 groups) Can you paste ipa user-show dpoulson? From darren.poulson at genesys.com Fri Nov 14 15:07:29 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Fri, 14 Nov 2014 15:07:29 +0000 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141114145615.GC12319@hendrix.brq.redhat.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com>, <20141114145615.GC12319@hendrix.brq.redhat.com> Message-ID: <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Jakub Hrozek [jhrozek at redhat.com] > Sent: 14 November 2014 14:56 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Group membership not populated > > On Fri, Nov 14, 2014 at 12:10:59PM +0000, Darren Poulson wrote: > > Hi, > > > > I'm currently having an issue where if I log in as a user on a freshly rebooted machine, their group membership > is not populated, so things like sudo do not work properly. If I do a getent group , log out and log back in > again, then it works properly. > > > > for example > > > > -sh-4.1$ groups dpoulson > > dpoulson : dpoulson ops_admins helpdesk > > -sh-4.1$ getent group ops_users > > ops_users:*:50130:dpoulson,anotheruser,andanother,etc > > Is ops_users an IPA group that dpoulsen is a member of (or maybe some AD > trust group or a local UNIX group)? > An IPA group, no AD or other funkiness in this set up yet. > > -sh-4.1$ groups dpoulson > > dpoulson : dpoulson ops_admins helpdesk ops_users > > -sh-4.1$ groups > > dpoulson ops_admins helpdesk > > > > > > > > -sh-4.1$ groups > > dpoulson helpdesk ops_admins ops_users > > Taking the missing ops_users group out of the picture, this is expected, > memberships are set on login only. > Agreed. > > > > (the user is actually meant to be a member of 6 groups) > > Can you paste ipa user-show dpoulson? [root at freeipa1-01 ~]# ipa user-show dpoulson User login: dpoulson First name: Darren Last name: Poulson Home directory: /home/dpoulson Login shell: /bin/sh Email address: dpoulson at genesys.com UID: 50004 GID: 50004 Telephone Number: 123-555-1234 Account disabled: False Password: True Member of groups: admins, ipausers, helpdesk, sbmonitor_users, ops_users, ops_admins Indirect Member of role: helpdesk Indirect Member of Sudo rule: sudo_admins Indirect Member of HBAC rule: allow_all Kerberos keys available: True SSH public key fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX darren.poulson at genesys.com (ssh-rsa) Cheers, Darren. -- 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 From jhrozek at redhat.com Fri Nov 14 15:14:14 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 14 Nov 2014 16:14:14 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141114151414.GD12319@hendrix.brq.redhat.com> On Fri, Nov 14, 2014 at 03:07:29PM +0000, Darren Poulson wrote: > > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Jakub Hrozek [jhrozek at redhat.com] > > Sent: 14 November 2014 14:56 > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Group membership not populated > > > > On Fri, Nov 14, 2014 at 12:10:59PM +0000, Darren Poulson wrote: > > > Hi, > > > > > > I'm currently having an issue where if I log in as a user on a freshly rebooted machine, their group membership > is not populated, so things like sudo do not work properly. If I do a getent group , log out and log back in > again, then it works properly. > > > > > > for example > > > > > > -sh-4.1$ groups dpoulson > > > dpoulson : dpoulson ops_admins helpdesk > > > -sh-4.1$ getent group ops_users > > > ops_users:*:50130:dpoulson,anotheruser,andanother,etc > > > > Is ops_users an IPA group that dpoulsen is a member of (or maybe some AD > > trust group or a local UNIX group)? > > > > An IPA group, no AD or other funkiness in this set up yet. > > > > -sh-4.1$ groups dpoulson > > > dpoulson : dpoulson ops_admins helpdesk ops_users > > > -sh-4.1$ groups > > > dpoulson ops_admins helpdesk > > > > > > > > > > > > -sh-4.1$ groups > > > dpoulson helpdesk ops_admins ops_users > > > > Taking the missing ops_users group out of the picture, this is expected, > > memberships are set on login only. > > > Agreed. > > > > > > > (the user is actually meant to be a member of 6 groups) > > > > Can you paste ipa user-show dpoulson? > > [root at freeipa1-01 ~]# ipa user-show dpoulson > User login: dpoulson > First name: Darren > Last name: Poulson > Home directory: /home/dpoulson > Login shell: /bin/sh > Email address: dpoulson at genesys.com > UID: 50004 > GID: 50004 > Telephone Number: 123-555-1234 > Account disabled: False > Password: True > Member of groups: admins, ipausers, helpdesk, sbmonitor_users, ops_users, ops_admins > Indirect Member of role: helpdesk > Indirect Member of Sudo rule: sudo_admins > Indirect Member of HBAC rule: allow_all > Kerberos keys available: True > SSH public key fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX darren.poulson at genesys.com (ssh-rsa) OK, if the user is a direct member of the groups and the groups are all POSIX (=they all have a GID), then I would expect the group membership to show all users. Can you try setting ldap_deref_threshold=0 and re-running the test? It would also be best if you could remove the sssd cache first. From darren.poulson at genesys.com Fri Nov 14 15:38:47 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Fri, 14 Nov 2014 15:38:47 +0000 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141114151414.GD12319@hendrix.brq.redhat.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com>, <20141114151414.GD12319@hendrix.brq.redhat.com> Message-ID: <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> > > OK, if the user is a direct member of the groups and the groups are all > POSIX (=they all have a GID), then I would expect the group membership > to show all users. > > Can you try setting ldap_deref_threshold=0 and re-running the test? It > would also be best if you could remove the sssd cache first. Ok, I added that into a [povider/ldap] block, but no change to the behaviour. I even cleared cache, rebooted, and tried again just for a bit of overkill. ipausers isn't a posix group, but the rest are. I removed ipausers for that user to make sure that wasn't causing an issue. From jhrozek at redhat.com Fri Nov 14 15:57:59 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 14 Nov 2014 16:57:59 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141114155759.GE12319@hendrix.brq.redhat.com> On Fri, Nov 14, 2014 at 03:38:47PM +0000, Darren Poulson wrote: > > > > > OK, if the user is a direct member of the groups and the groups are all > > POSIX (=they all have a GID), then I would expect the group membership > > to show all users. > > > > Can you try setting ldap_deref_threshold=0 and re-running the test? It > > would also be best if you could remove the sssd cache first. > > Ok, I added that into a [povider/ldap] block, but no change to the behaviour. I even cleared cache, rebooted, and tried again just for a bit of overkill. > > ipausers isn't a posix group, but the rest are. I removed ipausers for that user to make sure that wasn't causing an issue. > > > OK, at this point I think we need to see the SSSD debug logs... Can you put debug_level=7 to the [nss] and [domain] sections, remove the cache, restart sssd and then run id? Then attach the contents of /var/log/sssd/*.log ... From darren.poulson at genesys.com Fri Nov 14 16:30:17 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Fri, 14 Nov 2014 16:30:17 +0000 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141114155759.GE12319@hendrix.brq.redhat.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com>, <20141114155759.GE12319@hendrix.brq.redhat.com> Message-ID: <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> Ok, I've shoved them on pastebin. They were a bit big to put in a mailing list really. ldap_child.log: http://pastebin.com/qGCZF4vK sssd_nss.log: http://pastebin.com/gTBA8NEj sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z I did see this in the sssd_nss.log: (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 17 error message: Init group lookup failed (Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 17, Init group lookup failed Will try to return what we have in cache (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x418850:3:dpoulson at bur.us.genops] Which pointed to this: https://fedorahosted.org/sssd/ticket/2385 Which had similar symptoms but is related to AD. Cheers, Darren. ________________________________________ From: Jakub Hrozek [jhrozek at redhat.com] Sent: 14 November 2014 15:57 To: Darren Poulson Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Group membership not populated On Fri, Nov 14, 2014 at 03:38:47PM +0000, Darren Poulson wrote: > > > > > OK, if the user is a direct member of the groups and the groups are all > > POSIX (=they all have a GID), then I would expect the group membership > > to show all users. > > > > Can you try setting ldap_deref_threshold=0 and re-running the test? It > > would also be best if you could remove the sssd cache first. > > Ok, I added that into a [povider/ldap] block, but no change to the behaviour. I even cleared cache, rebooted, and tried again just for a bit of overkill. > > ipausers isn't a posix group, but the rest are. I removed ipausers for that user to make sure that wasn't causing an issue. > > > OK, at this point I think we need to see the SSSD debug logs... Can you put debug_level=7 to the [nss] and [domain] sections, remove the cache, restart sssd and then run id? Then attach the contents of /var/log/sssd/*.log ... From lslebodn at redhat.com Fri Nov 14 18:08:54 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 14 Nov 2014 19:08:54 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141114180853.GF6192@mail.corp.redhat.com> On (14/11/14 16:30), Darren Poulson wrote: >Ok, > >I've shoved them on pastebin. They were a bit big to put in a mailing list really. > >ldap_child.log: http://pastebin.com/qGCZF4vK >sssd_nss.log: http://pastebin.com/gTBA8NEj >sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z ^^^^^^^ this links is sssd_nss.log. becuas eit contains "[sssd[nss]]" Could you share log file from domain section? (sssd_bur.us.genops.log) > >I did see this in the sssd_nss.log: > >(Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 17 error message: Init group lookup failed >(Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider >Error: 3, 17, Init group lookup failed >Will try to return what we have in cache >(Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x418850:3:dpoulson at bur.us.genops] > >Which pointed to this: > >https://fedorahosted.org/sssd/ticket/2385 > >Which had similar symptoms but is related to AD. > No, we need to se domain log. LS From justeank at yahoo.com Fri Nov 14 19:17:49 2014 From: justeank at yahoo.com (Justean) Date: Fri, 14 Nov 2014 19:17:49 +0000 (UTC) Subject: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client Message-ID: <1902510701.423631.1415992669011.JavaMail.yahoo@jws10769.mail.gq1.yahoo.com> Our Redhat 5.10 servers that were moved into our IPA domain cannot run any IPA user's crons we can't even list the crons: crontab -l "you (username) are not allowed to access to (crontab) becauseof pam configuration" I don't know if I should be manually editing the /etc/pam.d/system-auth-ac and/or /etc/pam.d/crond to get this working and if so what I should put for the config. The client version is ipa-client-2.1.3-7.el5.x86_64 and the server version is ipa-server-3.0.0-42.el6.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Nov 14 19:43:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Nov 2014 14:43:06 -0500 Subject: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client In-Reply-To: <1902510701.423631.1415992669011.JavaMail.yahoo@jws10769.mail.gq1.yahoo.com> References: <1902510701.423631.1415992669011.JavaMail.yahoo@jws10769.mail.gq1.yahoo.com> Message-ID: <54665B4A.1020800@redhat.com> Justean wrote: > Our Redhat 5.10 servers that were moved into our IPA domain cannot run > any IPA user's crons we can't even list the crons: > > crontab -l "you (/username/) are not allowed to access to (crontab) > because of pam configuration" > > I don't know if I should be manually editing the > /etc/pam.d/system-auth-ac and/or /etc/pam.d/crond to get this working > and if so what I should put for the config. > > The client version is ipa-client-2.1.3-7.el5.x86_64 and the server > version is ipa-server-3.0.0-42.el6.x86_64 I would suspect this is due to HBAC. Do you use the HBAC feature? Perhaps you need to add rules for these hosts. rob From justeank at yahoo.com Fri Nov 14 20:24:34 2014 From: justeank at yahoo.com (Justean) Date: Fri, 14 Nov 2014 20:24:34 +0000 (UTC) Subject: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client In-Reply-To: <54665B4A.1020800@redhat.com> References: <54665B4A.1020800@redhat.com> Message-ID: <1455929718.431509.1415996674650.JavaMail.yahoo@jws10757.mail.gq1.yahoo.com> Ahh, I got you. We do use hbac rules, I did not think I need to add crond as a service to allow because it isn't even in the list of services available but I see that I do have to just manually add the service. Thank you, it is working now From: Rob Crittenden To: Justean ; "freeipa-users at redhat.com" Sent: Friday, November 14, 2014 11:43 AM Subject: Re: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client Justean wrote: > Our Redhat 5.10 servers that were moved into our IPA domain cannot run > any IPA user's crons we can't even list the crons: > > crontab -l "you (/username/) are not allowed to access to (crontab) > because of pam configuration" > > I don't know if I should be manually editing the > /etc/pam.d/system-auth-ac and/or /etc/pam.d/crond to get this working > and if so what I should put for the config. > > The client version is ipa-client-2.1.3-7.el5.x86_64 and the server > version is ipa-server-3.0.0-42.el6.x86_64 I would suspect this is due to HBAC. Do you use the HBAC feature? Perhaps you need to add rules for these hosts. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From justeank at yahoo.com Fri Nov 14 20:37:07 2014 From: justeank at yahoo.com (Justean) Date: Fri, 14 Nov 2014 20:37:07 +0000 (UTC) Subject: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client In-Reply-To: <1455929718.431509.1415996674650.JavaMail.yahoo@jws10757.mail.gq1.yahoo.com> References: <54665B4A.1020800@redhat.com> <1455929718.431509.1415996674650.JavaMail.yahoo@jws10757.mail.gq1.yahoo.com> Message-ID: <597460076.428321.1415997427270.JavaMail.yahoo@jws10793.mail.gq1.yahoo.com> I have one other possibly related question though. I also get access denied errors in the logs for local service accounts running crons or other services on my IPA client servers: pam_sss(crond:account):Access denied for user username: 10 (User not known to the underlying authentication module) pam_sss(sshd:account): Access denied for user username: 10 (User not known to the underlying authentication module) su: pam_sss(su-l:account): Access denied for user username: 10 (User not known to the underlying authentication module) These crons still run but errors fill the logs. SInce I can't add an external user to an HBAC rule I am not sure how to rectify From: Justean To: Rob Crittenden ; "freeipa-users at redhat.com" Sent: Friday, November 14, 2014 12:24 PM Subject: Re: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client Ahh, I got you. We do use hbac rules, I did not think I need to add crond as a service to allow because it isn't even in the list of services available but I see that I do have to just manually add the service. Thank you, it is working now From: Rob Crittenden To: Justean ; "freeipa-users at redhat.com" Sent: Friday, November 14, 2014 11:43 AM Subject: Re: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client Justean wrote: > Our Redhat 5.10 servers that were moved into our IPA domain cannot run > any IPA user's crons we can't even list the crons: > > crontab -l "you (/username/) are not allowed to access to (crontab) > because of pam configuration" > > I don't know if I should be manually editing the > /etc/pam.d/system-auth-ac and/or /etc/pam.d/crond to get this working > and if so what I should put for the config. > > The client version is ipa-client-2.1.3-7.el5.x86_64 and the server > version is ipa-server-3.0.0-42.el6.x86_64 I would suspect this is due to HBAC. Do you use the HBAC feature? Perhaps you need to add rules for these hosts. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Nov 14 22:01:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 15 Nov 2014 00:01:50 +0200 Subject: [Freeipa-users] user can't run crons after setting rhel 5 servers as ipa client In-Reply-To: <597460076.428321.1415997427270.JavaMail.yahoo@jws10793.mail.gq1.yahoo.com> References: <54665B4A.1020800@redhat.com> <1455929718.431509.1415996674650.JavaMail.yahoo@jws10757.mail.gq1.yahoo.com> <597460076.428321.1415997427270.JavaMail.yahoo@jws10793.mail.gq1.yahoo.com> Message-ID: <20141114220150.GN3493@redhat.com> On Fri, 14 Nov 2014, Justean wrote: >I have one other possibly related question though. I also get access >denied errors in the logs for local service accounts running crons or >other services on my IPA client servers: > >pam_sss(crond:account):Access denied for user username: 10 (User not >known to the underlying authentication module) > >pam_sss(sshd:account): Access denied for user username: 10 (User not >known to the underlying authentication module) su: >pam_sss(su-l:account): Access denied for user username: 10 (User not >known to the underlying authentication module) > >These crons still run but errors fill the logs. SInce I can't add an >external user to an HBAC rule I am not sure how to rectify. These messages can safely be ignored. PAM is a _stack_, multiple modules can be combined to serve together. It is perfectly OK and even expected that some modules in the stack will not make a decision as they don't know about the user in question. The second value in brackets is the type of PAM stack. In the log above you have account stack and indeed one of account modules has to succeed. Most likely pam_sss is earlier than pam_unix. You may see the reversed situation with pam_unix in the authentication stack -- it will complain it doesn't know about users provided by SSSD. However, it is all dependent on exact positioning of the modules in the PAM stack. -- / Alexander Bokovoy From techpkiuser at gmail.com Sat Nov 15 13:44:25 2014 From: techpkiuser at gmail.com (Kamal Perera) Date: Sat, 15 Nov 2014 19:14:25 +0530 Subject: [Freeipa-users] Urgent Help Needed - CA subsystem certificate renewal In-Reply-To: <5465E749.9000805@redhat.com> References: <5465D761.8080407@redhat.com> <5465E749.9000805@redhat.com> Message-ID: dear Martin, Thanks. I will check and update the list. On Fri, Nov 14, 2014 at 4:58 PM, Martin Kosek wrote: > You need to get all certificates in > > # getcert list > > renewed. With FreeIPA 3.0+ the certificates should be already properly > tracked, AFAIR. > > Was the uid=ipara,ou=People,o=ipaca entry (as described in > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal) properly updated > with a serial pointing to the new certificate? > > Maybe this is the reason why old RA certificate is loaded. > > If you are using RHEL/CentOS, I would also recommend updating ipa, > certmonger and selinux-policy to the 6.6 version is there were several > related fixes. > > Martin > > On 11/14/2014 11:56 AM, Kamal Perera wrote: > >> Hi Martin, >> >> Thanks for the reply. >> >> its FreeIPA 3. >> >> Actually my issue was, all my subsystem certificates were expired two days >> back. So it wasnt possible to get the requests signed and approved by the >> CA as >> the web interface in inaccessible. >> >> But after several attempts, I got it done by changing the date back to a >> valid >> time. Now i have revert back and everything is fine except this. >> >> now the RA and OCSPs are not communicating with the CA. >> >> I guess its because the CA's subsystem certificate is expired. So do i >> have to >> reissue all the subsystem certificates in RA and OCSP? >> >> Any thoughts? >> >> Thanks >> >> On Fri, Nov 14, 2014 at 3:50 PM, Martin Kosek > > wrote: >> >> On 11/14/2014 08:02 AM, pki tech wrote: >> >> Dear All, >> >> In our Issuing CA, all the subsystem certificates are expired >> except the >> caSigningCert. >> >> I can generate the new certificate requests via certutil, but how >> can i get >> them signed? >> >> your swift response is appreciated. >> >> Regards, >> Kamal >> >> >> What IPA version did you use? We have a related howto article on >> FreeIPA.org wiki with instructions what to do when PKI subsystem >> certificate expire: >> >> http://www.freeipa.org/page/__IPA_2x_Certificate_Renewal >> >> >> Also CCing Jan who owns the PKI knowledge. >> >> Martin >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darren.poulson at genesys.com Sat Nov 15 15:01:13 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Sat, 15 Nov 2014 15:01:13 +0000 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141114180853.GF6192@mail.corp.redhat.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com>, <20141114180853.GF6192@mail.corp.redhat.com> Message-ID: <26274E768E1C7F44A8406CD7AEE820EA0307B8E0@GENSJZMBX03.msg.int.genesyslab.com> Sorry, it seems I failed at cutting and pasting. sssd_bur.us.genops.log http://pastebin.com/7c5bH1Wq From lslebodn at redhat.com Sat Nov 15 15:17:29 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 15 Nov 2014 16:17:29 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA0307B8E0@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> <20141114180853.GF6192@mail.corp.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA0307B8E0@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141115151728.GA5568@mail.corp.redhat.com> On (15/11/14 15:01), Darren Poulson wrote: >Sorry, it seems I failed at cutting and pasting. > >sssd_bur.us.genops.log http://pastebin.com/7c5bH1Wq > Thank you very much for log file. It is know bug: https://fedorahosted.org/sssd/ticket/2471 https://bugzilla.redhat.com/show_bug.cgi?id=1154042 You can use workaround to fix this regression. Put following line into domain section in /etc/sssd/sssd.conf ldap_group_object_class = ipaUserGroup LS From andreas.ladanyi at kit.edu Mon Nov 17 12:59:44 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Mon, 17 Nov 2014 13:59:44 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <20141113093553.GE3493@redhat.com> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> Message-ID: <5469F140.9010802@kit.edu> > >>>> Hi, >>>> >>>> I set up the 389 LDAP server to support des-cbc-crc enctype. >>>> >>>> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 >>>> (single-DES). I created the principal with: >>>> >>>> kadmin.local -x ipa-setup-override-restrictions >>> Please don't do this, use the ipa service-add and ipa-getkeytab >>> commands instead. >> I cant use ipa service-add, because for OpenAFS i need a service >> principal called: >> >> afs/cellname at REALM , the cellname could be any name. In my case the >> cellname is the same like the domainname. > [root at cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test > --------------------------------------- > Added host "afs-cellname.ipacloud.test" > --------------------------------------- > Host name: afs-cellname.ipacloud.test > Principal name: host/afs-cellname.ipacloud.test at IPACLOUD.TEST > Password: False > Keytab: False > Managed by: afs-cellname.ipacloud.test > [root at cc21 ~]# ipa service-add --force afs/afs-cellname > ---------------------------------------------- > Added service "afs/afs-cellname at IPACLOUD.TEST" > ---------------------------------------------- > Principal: afs/afs-cellname at IPACLOUD.TEST > Managed by: afs-cellname.ipacloud.test > [root at cc21 ~]# ipa service-show afs/afs-cellname > Principal: afs/afs-cellname at IPACLOUD.TEST > Keytab: False > Managed by: afs-cellname.ipacloud.test > [root at cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname -k > /tmp/afs.keytab Keytab successfully retrieved and stored in: > /tmp/afs.keytab > > As you can see there is no problem at all -- all you need is to have a > host entry with the same name as afs-cellname. Note that the host > afs-cellname doesn't even need to exist in DNS. > > However, your primary problem would be in a different area. You'll need > to enable weak crypto at KDC server, Kerberos clients, and LDAP servers. > > krb5.conf (on both IPA masters and clients): > [libdefaults] > allow_weak_crypto = true > > /var/kerberos/krb5kdc/kdc.conf (on IPA masters): > [realms] > IPACLOUD.TEST = { > supported_enctypes = aes256-cts-hmac-sha1-96:normal > aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal > arcfour-hmac-md5:normal des-cbc-crc:v4 > } > > Finally, you need to modify > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > and add des-cbc-crc:v4 to supported Kerberos encryption types with > krbSupportedEncSaltTypes > attribute. You have to use ldapmodify as cn=Directory Manager for that > as we don't allow admins to modify these entries directly. > > A simplified approach would be to use ipa-ldap-updater with your own > update file (which should have a name like -.update where > is something between 01 and 90): > > [root at cc21 ~]# cat 20-weak-enctypes.update dn: > cn=$REALM,cn=kerberos,$SUFFIX > add: krbSupportedEncSaltTypes: des-cbc-crc:v4 > > [root at cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory > Manager password: > Parsing update file './20-weak-enctypes.update' > Updating existing entry: > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > Done > The ipa-ldap-updater command was successful > > Only after that you'll get ipa-getkeytab to generate weaker encryption > type-based keys. Thats interesting. Now i can receive afs/cellname at REALM service tickets with des-cbc-crc and aes256 key on the client but only when i execute: kvno -e des-cbc-crc afs/cellname If i execute aklog to obtain an afs token from tgt i get a afs/cellname at REALM service ticket without des-cbc-crc key. > However, we have a problem in FreeIPA 4.x that an > attempt to force only a specific encryption type in ipa-getkeytab is > ignored and instead only enctypes from krbDefaultEncSaltTypes attribute > are generated. This bug is tracked with > https://fedorahosted.org/freeipa/ticket/4718 > From darren.poulson at genesys.com Mon Nov 17 13:30:14 2014 From: darren.poulson at genesys.com (Darren Poulson) Date: Mon, 17 Nov 2014 13:30:14 +0000 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141115151728.GA5568@mail.corp.redhat.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> <20141114180853.GF6192@mail.corp.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA0307B8E0@GENSJZMBX03.msg.int.genesyslab.com>, <20141115151728.GA5568@mail.corp.redhat.com> Message-ID: <26274E768E1C7F44A8406CD7AEE820EA03083F31@GENSJZMBX03.msg.int.genesyslab.com> That seems to have done the trick. Many thanks to all who helped. Now to deploy this thing! :D ________________________________________ From: Lukas Slebodnik [lslebodn at redhat.com] Sent: 15 November 2014 15:17 To: Darren Poulson Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Group membership not populated On (15/11/14 15:01), Darren Poulson wrote: >Sorry, it seems I failed at cutting and pasting. > >sssd_bur.us.genops.log http://pastebin.com/7c5bH1Wq > Thank you very much for log file. It is know bug: https://fedorahosted.org/sssd/ticket/2471 https://bugzilla.redhat.com/show_bug.cgi?id=1154042 You can use workaround to fix this regression. Put following line into domain section in /etc/sssd/sssd.conf ldap_group_object_class = ipaUserGroup LS From dpal at redhat.com Mon Nov 17 13:31:39 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Nov 2014 08:31:39 -0500 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <5469F140.9010802@kit.edu> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> <5469F140.9010802@kit.edu> Message-ID: <5469F8BB.4070606@redhat.com> On 11/17/2014 07:59 AM, Andreas Ladanyi wrote: >>>>> Hi, >>>>> >>>>> I set up the 389 LDAP server to support des-cbc-crc enctype. >>>>> >>>>> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 >>>>> (single-DES). I created the principal with: >>>>> >>>>> kadmin.local -x ipa-setup-override-restrictions >>>> Please don't do this, use the ipa service-add and ipa-getkeytab >>>> commands instead. >>> I cant use ipa service-add, because for OpenAFS i need a service >>> principal called: >>> >>> afs/cellname at REALM , the cellname could be any name. In my case the >>> cellname is the same like the domainname. >> [root at cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test >> --------------------------------------- >> Added host "afs-cellname.ipacloud.test" >> --------------------------------------- >> Host name: afs-cellname.ipacloud.test >> Principal name: host/afs-cellname.ipacloud.test at IPACLOUD.TEST >> Password: False >> Keytab: False >> Managed by: afs-cellname.ipacloud.test >> [root at cc21 ~]# ipa service-add --force afs/afs-cellname >> ---------------------------------------------- >> Added service "afs/afs-cellname at IPACLOUD.TEST" >> ---------------------------------------------- >> Principal: afs/afs-cellname at IPACLOUD.TEST >> Managed by: afs-cellname.ipacloud.test >> [root at cc21 ~]# ipa service-show afs/afs-cellname >> Principal: afs/afs-cellname at IPACLOUD.TEST >> Keytab: False >> Managed by: afs-cellname.ipacloud.test >> [root at cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname -k >> /tmp/afs.keytab Keytab successfully retrieved and stored in: >> /tmp/afs.keytab >> >> As you can see there is no problem at all -- all you need is to have a >> host entry with the same name as afs-cellname. Note that the host >> afs-cellname doesn't even need to exist in DNS. >> >> However, your primary problem would be in a different area. You'll need >> to enable weak crypto at KDC server, Kerberos clients, and LDAP servers. >> >> krb5.conf (on both IPA masters and clients): >> [libdefaults] >> allow_weak_crypto = true >> >> /var/kerberos/krb5kdc/kdc.conf (on IPA masters): >> [realms] >> IPACLOUD.TEST = { >> supported_enctypes = aes256-cts-hmac-sha1-96:normal >> aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal >> arcfour-hmac-md5:normal des-cbc-crc:v4 >> } >> >> Finally, you need to modify >> cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test >> and add des-cbc-crc:v4 to supported Kerberos encryption types with >> krbSupportedEncSaltTypes >> attribute. You have to use ldapmodify as cn=Directory Manager for that >> as we don't allow admins to modify these entries directly. >> >> A simplified approach would be to use ipa-ldap-updater with your own >> update file (which should have a name like -.update where >> is something between 01 and 90): >> >> [root at cc21 ~]# cat 20-weak-enctypes.update dn: >> cn=$REALM,cn=kerberos,$SUFFIX >> add: krbSupportedEncSaltTypes: des-cbc-crc:v4 >> >> [root at cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory >> Manager password: >> Parsing update file './20-weak-enctypes.update' >> Updating existing entry: >> cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test >> Done >> The ipa-ldap-updater command was successful >> >> Only after that you'll get ipa-getkeytab to generate weaker encryption >> type-based keys. > Thats interesting. Now i can receive afs/cellname at REALM service tickets > with des-cbc-crc and aes256 key on the client but only when i execute: > > kvno -e des-cbc-crc afs/cellname > > If i execute aklog to obtain an afs token from tgt i get a > afs/cellname at REALM service ticket without des-cbc-crc key. Are they using same krb5.conf? > >> However, we have a problem in FreeIPA 4.x that an >> attempt to force only a specific encryption type in ipa-getkeytab is >> ignored and instead only enctypes from krbDefaultEncSaltTypes attribute >> are generated. This bug is tracked with >> https://fedorahosted.org/freeipa/ticket/4718 >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From janellenicole80 at gmail.com Mon Nov 17 14:43:05 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 17 Nov 2014 09:43:05 -0500 Subject: [Freeipa-users] strange replica creation problem Message-ID: <546A0979.1080503@gmail.com> Happy Monday everyone, I have a strange issue I am seeing with replica creations, but it does not seem to be consistent. Sometimes, when trying to install the replica I get errors trying to connect to the master via SSH: /[root at ipa3 ~]# ipa-replica-install /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg // //Directory Manager (existing master) password: // // //Run connection check to master// //Check connection from replica to remote master 'ipa2.xyzzy.com':// // Directory Service: Unsecure port (389): OK// // Directory Service: Secure port (636): OK// // Kerberos KDC: TCP (88): OK// // Kerberos Kpasswd: TCP (464): OK// // HTTP Server: Unsecure port (80): OK// // HTTP Server: Secure port (443): OK// // //The following list of ports use UDP protocol and would need to be// //checked manually:// // Kerberos KDC: UDP (88): SKIPPED// // Kerberos Kpasswd: UDP (464): SKIPPED// // //Connection from replica to master is OK.// //Start listening on required ports for remote master check// //Get credentials to log in to remote master// //admin at XYZZY.COM password: // // //Check SSH connection to remote master// //admin at ipa2.xyzzy.com's password: // //admin at ipa2.xyzzy.com's password: // //Could not SSH into remote host. Error output:// // OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013// // debug1: Reading configuration data /etc/ssh/ssh_config// // debug1: /etc/ssh/ssh_config line 51: Applying options for */ ssh via root and all the hosts - using keys - works just fine. I don't understand why this is happening on some hosts and not others. Any ideas? ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 17 14:55:45 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Nov 2014 09:55:45 -0500 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <5469F140.9010802@kit.edu> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> <5469F140.9010802@kit.edu> Message-ID: <20141117095545.487c491e@willson.usersys.redhat.com> On Mon, 17 Nov 2014 13:59:44 +0100 Andreas Ladanyi wrote: > > > >>>> Hi, > >>>> > >>>> I set up the 389 LDAP server to support des-cbc-crc enctype. > >>>> > >>>> I created a principal for OpenAFS. OpenAFS need des-cbc-crc:v4 > >>>> (single-DES). I created the principal with: > >>>> > >>>> kadmin.local -x ipa-setup-override-restrictions > >>> Please don't do this, use the ipa service-add and ipa-getkeytab > >>> commands instead. > >> I cant use ipa service-add, because for OpenAFS i need a service > >> principal called: > >> > >> afs/cellname at REALM , the cellname could be any name. In my case the > >> cellname is the same like the domainname. > > [root at cc21 ~]# ipa host-add --force afs-cellname.ipacloud.test > > --------------------------------------- > > Added host "afs-cellname.ipacloud.test" > > --------------------------------------- > > Host name: afs-cellname.ipacloud.test > > Principal name: host/afs-cellname.ipacloud.test at IPACLOUD.TEST > > Password: False > > Keytab: False > > Managed by: afs-cellname.ipacloud.test > > [root at cc21 ~]# ipa service-add --force afs/afs-cellname > > ---------------------------------------------- > > Added service "afs/afs-cellname at IPACLOUD.TEST" > > ---------------------------------------------- > > Principal: afs/afs-cellname at IPACLOUD.TEST > > Managed by: afs-cellname.ipacloud.test > > [root at cc21 ~]# ipa service-show afs/afs-cellname > > Principal: afs/afs-cellname at IPACLOUD.TEST > > Keytab: False > > Managed by: afs-cellname.ipacloud.test > > [root at cc21 ~]# ipa-getkeytab -s `hostname` -p afs/afs-cellname -k > > /tmp/afs.keytab Keytab successfully retrieved and stored in: > > /tmp/afs.keytab > > > > As you can see there is no problem at all -- all you need is to > > have a host entry with the same name as afs-cellname. Note that the > > host afs-cellname doesn't even need to exist in DNS. > > > > However, your primary problem would be in a different area. You'll > > need to enable weak crypto at KDC server, Kerberos clients, and > > LDAP servers. > > > > krb5.conf (on both IPA masters and clients): > > [libdefaults] > > allow_weak_crypto = true > > > > /var/kerberos/krb5kdc/kdc.conf (on IPA masters): > > [realms] > > IPACLOUD.TEST = { > > supported_enctypes = aes256-cts-hmac-sha1-96:normal > > aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal > > arcfour-hmac-md5:normal des-cbc-crc:v4 > > } > > > > Finally, you need to modify > > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > > and add des-cbc-crc:v4 to supported Kerberos encryption types with > > krbSupportedEncSaltTypes > > attribute. You have to use ldapmodify as cn=Directory Manager for > > that as we don't allow admins to modify these entries directly. > > > > A simplified approach would be to use ipa-ldap-updater with your own > > update file (which should have a name like -.update > > where is something between 01 and 90): > > > > [root at cc21 ~]# cat 20-weak-enctypes.update dn: > > cn=$REALM,cn=kerberos,$SUFFIX > > add: krbSupportedEncSaltTypes: des-cbc-crc:v4 > > > > [root at cc21 ~]# ipa-ldap-updater ./20-weak-enctypes.update Directory > > Manager password: > > Parsing update file './20-weak-enctypes.update' > > Updating existing entry: > > cn=IPACLOUD.TEST,cn=kerberos,dc=ipacloud,dc=test > > Done > > The ipa-ldap-updater command was successful > > > > Only after that you'll get ipa-getkeytab to generate weaker > > encryption type-based keys. > > Thats interesting. Now i can receive afs/cellname at REALM service > tickets with des-cbc-crc and aes256 key on the client but only when i > execute: > > kvno -e des-cbc-crc afs/cellname > > If i execute aklog to obtain an afs token from tgt i get a > afs/cellname at REALM service ticket without des-cbc-crc key. This is probably because you got all default enctypes in the key, so the KDC is sending you a ticket with the strongest keytype for which it has a shared key with the service. > > However, we have a problem in FreeIPA 4.x that an > > attempt to force only a specific encryption type in ipa-getkeytab is > > ignored and instead only enctypes from krbDefaultEncSaltTypes > > attribute are generated. This bug is tracked with > > https://fedorahosted.org/freeipa/ticket/4718 This is the bug that is causing your last issue ^^ One way around it is to use an older ipa-getkeytab binary (like the one on RHEL 6) that uses the old setkeytab control. We are working on a fix upstream and will land it asap. Simo. -- Simo Sorce * Red Hat, Inc * New York From guigne at lms.polytechnique.fr Mon Nov 17 15:22:41 2014 From: guigne at lms.polytechnique.fr (=?UTF-8?B?RWRvdWFyZCBHdWlnbsOp?=) Date: Mon, 17 Nov 2014 16:22:41 +0100 Subject: [Freeipa-users] Questions about commande ipa user-add used to import NIS accounts Message-ID: <546A12C1.1080400@lms.polytechnique.fr> Hello freeipa users I followed the instructions of this page : http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords in order to integrate NIS accounts over IPA with preserving passwords. However, I do not succeed to import user as indicate on documentation : # ipa user-add /user1/--setattr=userpassword={CRYPT}/xxxxxxxxxxxx/ return : *"ipa: ERROR: Constraint violation : invalid password syntax - passwords with storage scheme are not allowed"* Someone could help ? Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Mon Nov 17 15:57:41 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 17 Nov 2014 15:57:41 +0000 Subject: [Freeipa-users] strange replica creation problem In-Reply-To: <546A0979.1080503@gmail.com> References: <546A0979.1080503@gmail.com> Message-ID: <4d17c0b87e9d458ca5afcb6be2a23e9b@BLUPR08MB488.namprd08.prod.outlook.com> Janelle, this may not be that useful but I found it worthwhile to resort to? ?skip-conncheck When setting up the replica ? pretty much for the same reason. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Janelle Sent: Monday, November 17, 2014 7:43 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] strange replica creation problem Happy Monday everyone, I have a strange issue I am seeing with replica creations, but it does not seem to be consistent. Sometimes, when trying to install the replica I get errors trying to connect to the master via SSH: [root at ipa3 ~]# ipa-replica-install /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipa2.xyzzy.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at XYZZY.COM password: Check SSH connection to remote master admin at ipa2.xyzzy.com's password: admin at ipa2.xyzzy.com's password: Could not SSH into remote host. Error output: OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 51: Applying options for * ssh via root and all the hosts - using keys - works just fine. I don't understand why this is happening on some hosts and not others. Any ideas? ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From jhrozek at redhat.com Mon Nov 17 16:59:15 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 17 Nov 2014 17:59:15 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <20141117165915.GA15378@Jakubs-MBP.lan> On Fri, Nov 14, 2014 at 04:30:17PM +0000, Darren Poulson wrote: > Ok, > > I've shoved them on pastebin. They were a bit big to put in a mailing list really. > > ldap_child.log: http://pastebin.com/qGCZF4vK > sssd_nss.log: http://pastebin.com/gTBA8NEj > sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z Seems like this is another instance of sssd_nss.log ? > > I did see this in the sssd_nss.log: > > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 17 error message: Init group lookup failed > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 17, Init group lookup failed Right, this is the problem. I'm not sure what's wrong, sssd domain log would tell us more.. > Will try to return what we have in cache > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x418850:3:dpoulson at bur.us.genops] > > Which pointed to this: > > https://fedorahosted.org/sssd/ticket/2385 > > Which had similar symptoms but is related to AD. Yes, I'm afraid we're looking at a different issue, #2385 was indeed AD-specific. From janellenicole80 at gmail.com Mon Nov 17 17:26:24 2014 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 17 Nov 2014 12:26:24 -0500 Subject: [Freeipa-users] strange replica creation problem In-Reply-To: <4d17c0b87e9d458ca5afcb6be2a23e9b@BLUPR08MB488.namprd08.prod.outlook.com> References: <546A0979.1080503@gmail.com> <4d17c0b87e9d458ca5afcb6be2a23e9b@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <546A2FC0.6050203@gmail.com> I did find that as the work-around - just trying to understand why it comes up sometimes... Did you find any issues with the workings of a replica if you had to resort to this method? Thanks. ~J On 11/17/14 10:57 AM, Craig White wrote: > > Janelle, this may not be that useful but I found it worthwhile to > resort to? > > ?skip-conncheck > > When setting up the replica ? pretty much for the same reason. > > Craig White > > System Administrator > > O623-201-8179 M602-377-9752 > > cid:image001.png at 01CF86FE.42D51630 > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Janelle > *Sent:* Monday, November 17, 2014 7:43 AM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] strange replica creation problem > > Happy Monday everyone, > > I have a strange issue I am seeing with replica creations, but it does > not seem to be consistent. Sometimes, when trying to install the > replica I get errors trying to connect to the master via SSH: > > /[root at ipa3 ~]# ipa-replica-install > /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'ipa2.xyzzy.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at XYZZY.COM password: > > Check SSH connection to remote master > admin at ipa2.xyzzy.com 's password: > admin at ipa2.xyzzy.com 's password: > Could not SSH into remote host. Error output: > OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 51: Applying options for */ > > > ssh via root and all the hosts - using keys - works just fine. I don't > understand why this is happening on some hosts and not others. > > > Any ideas? > ~J > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7660 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 17 18:22:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Nov 2014 13:22:18 -0500 Subject: [Freeipa-users] strange replica creation problem In-Reply-To: <546A2FC0.6050203@gmail.com> References: <546A0979.1080503@gmail.com> <4d17c0b87e9d458ca5afcb6be2a23e9b@BLUPR08MB488.namprd08.prod.outlook.com> <546A2FC0.6050203@gmail.com> Message-ID: <546A3CDA.6020706@redhat.com> Janelle wrote: > I did find that as the work-around - just trying to understand why it > comes up sometimes... > Did you find any issues with the workings of a replica if you had to > resort to this method? The conncheck is a reaction to a slew of problems people had setting up replicas and because we don't have direct firewall integration. It provides a way to detect errors that will eventually cause an installation to fail. It isn't necessary to run which is why we provided the skip option. As for why the ssh fails, you'd need to check the system logs on the IPA master where it is failing. The ssh is only used so we can test the reverse connection, it isn't used once the installation itself starts. rob > > Thanks. > > ~J > > On 11/17/14 10:57 AM, Craig White wrote: >> >> Janelle, this may not be that useful but I found it worthwhile to >> resort to >> >> >> >> ?skip-conncheck >> >> >> >> When setting up the replica ? pretty much for the same reason. >> >> >> >> Craig White >> >> System Administrator >> >> O623-201-8179 M602-377-9752 >> >> >> >> cid:image001.png at 01CF86FE.42D51630 >> >> >> >> SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 >> >> >> >> *From:*freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Janelle >> *Sent:* Monday, November 17, 2014 7:43 AM >> *To:* freeipa-users at redhat.com >> *Subject:* [Freeipa-users] strange replica creation problem >> >> >> >> Happy Monday everyone, >> >> I have a strange issue I am seeing with replica creations, but it does >> not seem to be consistent. Sometimes, when trying to install the >> replica I get errors trying to connect to the master via SSH: >> >> /[root at ipa3 ~]# ipa-replica-install >> /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg >> Directory Manager (existing master) password: >> >> Run connection check to master >> Check connection from replica to remote master 'ipa2.xyzzy.com': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> The following list of ports use UDP protocol and would need to be >> checked manually: >> Kerberos KDC: UDP (88): SKIPPED >> Kerberos Kpasswd: UDP (464): SKIPPED >> >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> admin at XYZZY.COM password: >> >> Check SSH connection to remote master >> admin at ipa2.xyzzy.com 's password: >> admin at ipa2.xyzzy.com 's password: >> Could not SSH into remote host. Error output: >> OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: /etc/ssh/ssh_config line 51: Applying options for */ >> >> >> ssh via root and all the hosts - using keys - works just fine. I don't >> understand why this is happening on some hosts and not others. >> >> >> Any ideas? >> ~J >> > > > From rcritten at redhat.com Mon Nov 17 18:25:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Nov 2014 13:25:36 -0500 Subject: [Freeipa-users] Questions about commande ipa user-add used to import NIS accounts In-Reply-To: <546A12C1.1080400@lms.polytechnique.fr> References: <546A12C1.1080400@lms.polytechnique.fr> Message-ID: <546A3DA0.7000407@redhat.com> Edouard Guign? wrote: > Hello freeipa users > > I followed the instructions of this page : > http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords > > in order to integrate NIS accounts over IPA with preserving passwords. > > However, I do not succeed to import user as indicate on documentation : > > # ipa user-add /user1/--setattr=userpassword={CRYPT}/xxxxxxxxxxxx/ > return : > *"ipa: ERROR: Constraint violation : invalid password syntax - passwords > with storage scheme are not allowed"* > > Someone could help ? You enabled migration mode? ipa config-mod --enable-migration=true If you have, what version of IPA is this? rob From jhrozek at redhat.com Mon Nov 17 18:48:27 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 17 Nov 2014 19:48:27 +0100 Subject: [Freeipa-users] Group membership not populated In-Reply-To: <20141117165915.GA15378@Jakubs-MBP.lan> References: <26274E768E1C7F44A8406CD7AEE820EA03077524@GENSJZMBX03.msg.int.genesyslab.com> <20141114145615.GC12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03077CC4@GENSJZMBX03.msg.int.genesyslab.com> <20141114151414.GD12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03078047@GENSJZMBX03.msg.int.genesyslab.com> <20141114155759.GE12319@hendrix.brq.redhat.com> <26274E768E1C7F44A8406CD7AEE820EA03079A31@GENSJZMBX03.msg.int.genesyslab.com> <20141117165915.GA15378@Jakubs-MBP.lan> Message-ID: <20141117184827.GC15378@Jakubs-MBP.lan> On Mon, Nov 17, 2014 at 05:59:15PM +0100, Jakub Hrozek wrote: > On Fri, Nov 14, 2014 at 04:30:17PM +0000, Darren Poulson wrote: > > Ok, > > > > I've shoved them on pastebin. They were a bit big to put in a mailing list really. > > > > ldap_child.log: http://pastebin.com/qGCZF4vK > > sssd_nss.log: http://pastebin.com/gTBA8NEj > > sssd_bur.us.genops.log: http://pastebin.com/ithUqb1z > > Seems like this is another instance of sssd_nss.log ? > > > > > I did see this in the sssd_nss.log: > > > > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 17 error message: Init group lookup failed > > (Fri Nov 14 16:09:34 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider > > Error: 3, 17, Init group lookup failed > > Right, this is the problem. I'm not sure what's wrong, sssd domain log > would tell us more.. Ah, sorry, I replied to your mail in my INBOX before seeing the rest of the discussion on the list. Happy it works now! From christoph.kaminski at biotronik.com Tue Nov 18 06:07:35 2014 From: christoph.kaminski at biotronik.com (Christoph Kaminski) Date: Tue, 18 Nov 2014 07:07:35 +0100 Subject: [Freeipa-users] Multiple Domains and SSH Message-ID: Hi I can reach each host here via ssh on multiple domains: host.mydom.int host mydom.net host.mgmt sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever "The authenticity of host 'host.mydom.int ()' can't be established."... why? it is possible to make it working for the other domains to? MfG Christoph Kaminski www.biotronik.com BIOTRONIK - excellence for life Established with the development of the first German pacemaker in 1963, BIOTRONIK has upheld the highest quality standards in the fields of cardiac rhythm management and vascular intervention in more than 100 countries worldwide. We?ve developed advanced technologies and products such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI?, an advanced technology that gives patients access to magnetic resonance (MR) scanning. BIOTRONIK SE & Co. KG Woermannkehre 1, 12359 Berlin, Germany Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 Vertreten durch ihre Komplement?rin: BIOTRONIK MT SE Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoqiang3243 at gmail.com Tue Nov 18 07:13:56 2014 From: xiaoqiang3243 at gmail.com (Zhong Qiang) Date: Tue, 18 Nov 2014 15:13:56 +0800 Subject: [Freeipa-users] Integrating with NIS Domains and Netgroups Message-ID: hi, I have some hosts installed centos4.8/6.5/5.9,and want to centralize identity/policy/authorization.but ipa client isn't compatible with centos4.8,so I try to configure FreeIPA integrated with NIS Domains. IPAserver:centos7 (+DNS) nisclient:centos4.8 ipaclient:centos6.6 I followed the instructions of this page: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/nis.html,to add netgroup(nis_test) and users(zhongq).then configured nis client installed centos4.8.on the nis client, I could get users data ,look like that: [root at nisclient ~]# getent passwd zhongq zhongq:*:724800001:724800001:??? ?:/home/zhongq:/bin/sh However,I do not succeed to log into nisclient with zhongq account. Any ideas? Regards, zhongq -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Tue Nov 18 08:54:14 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 18 Nov 2014 08:54:14 +0000 (UTC) Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <54630D8F.2020002@redhat.com> References: <54630D8F.2020002@redhat.com> Message-ID: <2001848902.1902142.1416300854811.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> Hello all I have a question regarding the log in in IPA well I didn't expect this to happen since last week all installation went smoothly and the adding of the clients as well but now I have another problem.? My first problem was ntp/ntpdate wasn't cooperating well and it won't update my fedora 20 time correctly every reboot, so I get the wrong time and manually issue the ntpdate just to get the correct time... ( well this problem is small )? So what I did was just configured/updated the timezone of the Freeipa Server. then I tried rebooting it 3 times in a row just to make sure it won't change time. and it was successful. ?( I did this last friday ) yesterday I checked the time of the free ipa server. and it was way off.. Now my problem is that if I edited the time or restarted ntpd / ntpdate?I cannot log-in to the web UI of freeipa although I'm using the admin account and the right credentials as well , It asks me to configure the browser credentials ( the one going to about:config ) but I still cannot log in, And I don't really know why .. But if I didn't I can Log in smoothly.. any Ideas on whats causing this error? TIA :)? On Tuesday, November 11, 2014 11:34 PM, Martin Kosek wrote: On 11/12/2014 04:09 AM, Rolf Nufable wrote: > I have another question, well I've achieved the state where I can't log in to my admin account in the server side, it happens because I'm changing the time of the server machine. > > but the time is really wrong. and I disabled NTP and the server has no access to the internet. > > these are my network configurations. > > peerdns = no > ipaddr? = 192.168.1.1 > netmask = 255.255.255.0 > dns1 = 192.168.1.1 > onboot = yes > > as you can see I've made the server also the dns1, (is this correct though ? i really don't know ) > > feel free to correct my network config > > And another problem is that I need to sync my freeipa server time to the right time zone? if thats the case then I do need internet connection for my Freeipa server , so that it could access ntp servers right?? ( or am I wrong? ) Yes, internet connection helps. Theoretically you could just set up the time manually on your FreeIPA server and then let your clients synchronize their time with it as NTP is running there, but that may be cumbersome. > > still this is a great breakthrough for my work > > Now what to do? FreeIPA server and the KDC do not care about the time zone, it works with UTC time anyway, AFAIK. You just simply need to have the time synchronized on all your servers and clients or Kerberos protocol will not work. > ps. Martin attached is the krb5kdc.log after I changed the time of the server.? Httpd error log didnt changed at all after I tried to access the web UI and tried to log in.. I saw no error there... > > > TIA > > > > On Tuesday, November 11, 2014 7:10 PM, Petr Vobornik wrote: >? > > > On 11.11.2014 11:11, Jakub Hrozek wrote: >> On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: >>> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) >>> >>> well I'm having this error in the client side when using the command su - ( user ) >>> >>> su - user at example.com >>> >>> su : user at example.com does not exist. >> >> Are you sure ipa-client-install did run successfully on that machine? >> >> Can you unenroll and enroll the client back so that we start from an >> sssd.conf that is created by the tooling? >> >> As Martin said, you don't need those sudo-related config options with >> recent SSSD releases, they wouldn't work in the sudo section anyway. > > Does: > > $ id user at example.com > > return you the user info? > > if not and ipa-client-install was run successfully before, check > nsswitch.conf if it has sssd configured (sss next to various providers). > > if not run: > $ authconfig --enablesssd --update > > if it doesn't help, try to run: > $ authconfig --disablesssd --update > $ authconfig --enablesssd --update > > if it helps, please tell me. I'm curious if you suffer from one issue I > experienced. > > > >> >>> >>> >>> >>> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: >>> >>> >>> >>> It is still really hard to give advise as I do not know what's actually wrong. >>> So are you trying to set up a sudo on your client or are you trying to log in >>> with your client browser to FreeIPA server? These are 2 orthogonal actions. >>> >>> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I >>> cannot help you without described procedure you are trying to do, logs and >>> exact error messages. >>> >>> Martin >>> >>> >>> On 11/11/2014 09:32 AM, Rolf Nufable wrote: >>>> never mind the problem on the server side, somehow it got fixed , I really don't know how though >>>> >>>> so in the client side , It is successful when installing free ipa client and the >>>? server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) >>>> >>>> So I really don't know why Can't I connect to the ipa server. >>>> >>>> Iptables works fine. >>>> /etc/resolv.conf is file as well >>>> >>>> sssd/sssd.conf ( added these lines ) >>>> [sudo] >>>> sudo_provider = ldap >>>> ldap_uri = ldap://myipaserver.example.com >>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>> ldap_sasl_mech = GSSAPI >>>> ldap_sasl_authid = host/myipaserver.example.com >>>> ldap_sasl_realm = EXAMPLE.COM >>>> krb_server = myipaserver.example.com >>>> >>>> >>>> and /etc/nsswitch.conf >>>> (added this line ) >>>> >>>> sudoers : files sss ldap >>>> >>>> is there something missing ? >>>> >>>> >>>> >>>> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: >>>> >>>> >>>> >>>> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either >>>? you are on the server or client side, or at least thats what I remember. >>>> >>>> Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs >>>> >>>> >>>> >>>> >>>> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: >>>> >>>> >>>> >>>> On 11/11/2014 08:07 AM, Rolf Nufable wrote: >>>>> well I dont know how or what command to use to display the logs, could you teach me how? >>>> >>>> There should be HOWTO articles on how to do that. Jakub may have better >>>> sources, but I see for >>>? example: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html >>>> >>>>> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only >>>> >>>> network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. >>>> >>>>> while on the client side, even >>>>? though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. >>>> >>>> FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, >>>> if SSO login fails. Does at least this part work? Because if not, there is some >>>> error on the server side. It would be interesting to check if there are no >>>> errors on the server in following logs: >>>> - /var/log/httpd/error_log >>>> - /var/log/krb5kdc.log >>>> >>>> >>>> >>>>> >>>>> TIA >>>>> >>>>> >>>>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >>>>> >>>>> >>>>> >>>>> On 11/11/2014 06:37 AM, Rolf Nufable >>>? wrote: >>>>>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >>>>> >>>>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >>>>> deploy, on the >>>>? contrary, it should be much cooler than 3.3. >>>>> >>>>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>>>>> >>>>>> >>>>>> >>>>>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>>>>> >>>>>> sudo_provider = ldap >>>>>> ldap_uri = ldap://myipaserver.example.com >>>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>>> ldap_sasl_mech = >>>>? GSSAPI >>>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>>> ldap_sasl_realm = EXAMPLE.COM >>>>>> krb_server = myipaserver.example.com >>>>> >>>>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >>>>> provider. Actually, FreeIPA 4.0+ clients do that for you. >>>>> >>>>> More info here: >>>>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>>> https://fedorahosted.org/freeipa/ticket/3358 >>>>> >>>>>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >>>>> >>>>> Are you sure that network.negotiate-auth.trusted-uris in about:config >>>>> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >>>>> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >>>>> is the setting of network.negotiate-auth.trusted-uris? >>>>> >>>>> In any case, it is still hard to >>>>? advise as I still did not see any related >>>>> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> >>>>>> >>>>>> >>>>>> TIA >>>>>> >>>>>> >>>>>> >>>>>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>>>>> >>>>>>> On 11/10/2014 02:05 AM, Rolf >>>>>>? Nufable wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>>>>> >>>>>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it >>>>? in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question >>>? is how can I solve this problem?? I've been at it for 3 weeks now .. >>>>>>> >>>>>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>>>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>>>>> CCing Lukas and Jakub to advise. >>>>>> >>>>>> Sorry, I skipped this thread b/c the subject didn't look like it was >>>>>> SSSD-related. >>>>>> >>>>>> I think we need to examine SSSD logs... >>>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbischof at hrz.uni-kassel.de Tue Nov 18 13:05:04 2014 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Tue, 18 Nov 2014 14:05:04 +0100 (CET) Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <545D2B79.7000200@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> Message-ID: Hi, On Fri, 7 Nov 2014, Dmitri Pal wrote: > On 11/07/2014 01:24 AM, Will Sheldon wrote: >> On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com >> ) wrote: >>> On 11/07/2014 12:18 AM, Will Sheldon wrote: >>>> >>>> On the whole we are loving FreeIPA, Many thanks and much respect to >>>> all involved, we?ve had a great 12-18 months hassle free use out of >>>> it - it is a fantastically stable trouble free solution? however now >>>> we?ve run into a small issue we (as mere mortals) are finding it hard >>>> to resolve :-/ >>>> >>>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything >>>> seems to go well, but one server is behaving oddly. It?s likely not >>>> an IPA issue, it also reset it?s hostname somehow after the upgrade >>>> (it?s an image in an openstack environment) >>>> >>>> If anyone has any pointers as to how to debug I?d be hugely >>>> appreciative :) >>>> >>>> Two servers, server1.domain.com and server2.domain.com >>>> >>>> Server1 can?t push data to server2, there are updates and new records >>>> on server1 that do not exist on server2. >>>> >>>> >>>> from the logs on server1: >>>> >>>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to send >>>> endReplication extended operation (Can't contact LDAP server) >>>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with >>>> GSSAPI auth resumed >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >>>> replicate schema: rc=2 >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to replay >>>> change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will >>>> retry later. >>> >>> Try to see >>> a) Server 1 properly resolves server 2 >>> b) You can connect from server 1 to server 2 using ldapsearch >>> c) your firewall has proper ports open >>> d) dirserver on server 2 is actually running >> >> All seems working: >> >> [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' >> namingContexts > > Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y > switch? is this resolved? I observe it on my systems, too. Exact same symptoms. ldapsearch with "-Y GSSAPI" works. > Did you find anything in the server2 logs? On my "server2", I see "sasl_io_recv failed to decode packet for connection #". Could there be something wrong with default buffer sizes as described in https://bugzilla.redhat.com/show_bug.cgi?id=953653 I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my database is rather small: ~30 users, <10 hosts and services. >> # extended LDIF >> # >> # LDAPv3 >> # base <> with scope baseObject >> # filter: (objectclass=*) >> # requesting: namingContexts >> # >> >> # >> dn: >> namingContexts: dc=domain,dc=com >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> [root at server1 ~]# >> >> And: >> >> [root at server2 ~]# /etc/init.d/dirsrv status >> dirsrv DOMAIN-COM (pid 1009) is running... >> dirsrv PKI-IPA (pid 1083) is running... >> [root at server2 ~]# >> >>> >>> Check logs on server 2 to see whether it actually sees an attempt to >>> connect, I suspect not, so it is most likely a DNS/FW issue or dir server >>> is not running on 2. >>>> >>>> >>>> and the servers: >>>> >>>> [root at server1 ~]# ipa-replica-manage list -v `hostname` >>>> Directory Manager password: >>>> >>>> server2.domain.com: replica >>>> last init status: None >>>> last init ended: None >>>> last update status: 0 Replica acquired successfully: Incremental update >>>> started >>>> last update ended: 2014-11-07 01:35:58+00:00 >>>> [root at server1 ~]# >>>> >>>> >>>> >>>> [root at server2 ~]# ipa-replica-manage list -v `hostname` >>>> Directory Manager password: >>>> >>>> server1.domain.com: replica >>>> last init status: None >>>> last init ended: None >>>> last update status: 0 Replica acquired successfully: Incremental update >>>> succeeded >>>> last update ended: 2014-11-07 01:35:43+00:00 >>>> [root at server2 ~]# Mit freundlichen Gruessen/With best regards, --Daniel. From andreas.ladanyi at kit.edu Tue Nov 18 14:11:01 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Tue, 18 Nov 2014 15:11:01 +0100 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <20141117095545.487c491e@willson.usersys.redhat.com> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> <5469F140.9010802@kit.edu> <20141117095545.487c491e@willson.usersys.redhat.com> Message-ID: <546B5375.4030104@kit.edu> Hi Simo, >> Thats interesting. Now i can receive afs/cellname at REALM service >> tickets with des-cbc-crc and aes256 key on the client but only when i >> execute: >> >> kvno -e des-cbc-crc afs/cellname >> >> If i execute aklog to obtain an afs token from tgt i get a >> afs/cellname at REALM service ticket without des-cbc-crc key. > This is probably because you got all default enctypes in the key, so > the KDC is sending you a ticket with the strongest keytype for which it > has a shared key with the service. > >>> However, we have a problem in FreeIPA 4.x that an >>> attempt to force only a specific encryption type in ipa-getkeytab is >>> ignored and instead only enctypes from krbDefaultEncSaltTypes >>> attribute are generated. This bug is tracked with >>> https://fedorahosted.org/freeipa/ticket/4718 > This is the bug that is causing your last issue ^^ > > One way around it is to use an older ipa-getkeytab binary (like the one > on RHEL 6) that uses the old setkeytab control. > > We are working on a fix upstream and will land it asap. > > Simo. In the lines above i read that the bug is in FreeIPA 4.x. Does this bug also belongs to FreeIPA Release 3.3.6 (which i use in Fedora) or only 4.x ? Thanks a lot, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5306 bytes Desc: S/MIME Cryptographic Signature URL: From simo at redhat.com Tue Nov 18 14:28:24 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 09:28:24 -0500 Subject: [Freeipa-users] FreeIPA Kerberos and Single-DES for OpenAFS In-Reply-To: <546B5375.4030104@kit.edu> References: <54637496.9030508@kit.edu> <20141112201745.31eeab14@willson.usersys.redhat.com> <54647022.1070004@kit.edu> <20141113093553.GE3493@redhat.com> <5469F140.9010802@kit.edu> <20141117095545.487c491e@willson.usersys.redhat.com> <546B5375.4030104@kit.edu> Message-ID: <20141118092824.4e53a4e2@willson.usersys.redhat.com> On Tue, 18 Nov 2014 15:11:01 +0100 Andreas Ladanyi wrote: > Hi Simo, > >> Thats interesting. Now i can receive afs/cellname at REALM service > >> tickets with des-cbc-crc and aes256 key on the client but only > >> when i execute: > >> > >> kvno -e des-cbc-crc afs/cellname > >> > >> If i execute aklog to obtain an afs token from tgt i get a > >> afs/cellname at REALM service ticket without des-cbc-crc key. > > This is probably because you got all default enctypes in the key, so > > the KDC is sending you a ticket with the strongest keytype for > > which it has a shared key with the service. > > > >>> However, we have a problem in FreeIPA 4.x that an > >>> attempt to force only a specific encryption type in ipa-getkeytab > >>> is ignored and instead only enctypes from krbDefaultEncSaltTypes > >>> attribute are generated. This bug is tracked with > >>> https://fedorahosted.org/freeipa/ticket/4718 > > This is the bug that is causing your last issue ^^ > > > > One way around it is to use an older ipa-getkeytab binary (like the > > one on RHEL 6) that uses the old setkeytab control. > > > > We are working on a fix upstream and will land it asap. > > > > Simo. > In the lines above i read that the bug is in FreeIPA 4.x. > > Does this bug also belongs to FreeIPA Release 3.3.6 (which i use in > Fedora) or only 4.x ? Only 4.x as far as I know, sorry I thought you were testing 4. Simo. -- Simo Sorce * Red Hat, Inc * New York From CWhite at skytouchtechnology.com Tue Nov 18 15:37:04 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 18 Nov 2014 15:37:04 +0000 Subject: [Freeipa-users] cloning joined systems Message-ID: <75e9bcfb27b14089b9f21950fb7e86eb@BLUPR08MB488.namprd08.prod.outlook.com> Had a question from one of our engineers. It seems we are a lazy bunch and have a sometime methodology of using vSphere/vmWare to clone running virtual machines. I cannot think of any way to take a virtual machine that has already been joined to RedHat iDM (freeipa), clone it and then deal with it safely but is there any supportable way to rename the box, and join it again? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From rcritten at redhat.com Tue Nov 18 15:41:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Nov 2014 10:41:21 -0500 Subject: [Freeipa-users] Questions about commande ipa user-add used to import NIS accounts In-Reply-To: <546B46C5.204@lms.polytechnique.fr> References: <546A12C1.1080400@lms.polytechnique.fr> <546A3DA0.7000407@redhat.com> <546B46C5.204@lms.polytechnique.fr> Message-ID: <546B68A1.6020005@redhat.com> Edouard Guign? wrote: > Hello Rob, > > I looked for more informations about error message, and I found that : > http://comments.gmane.org/gmane.linux.redhat.freeipa.user/11952 > > So I change cn=config : > > ldapmodify -x -D "cn=directory manager" -w password > dn: cn=config > changetype: modify > replace: nsslapd-allow-hashed-passwords > *nsslapd-allow-hashed-passwords: on* > > Then try again : > > # ipa user-add user1 --last="User1" --first="myuser1" --setattr userpassword="{CRYPT}xxxxxxxxxxxx" > --------------------------- > Utilisateur "user1" ajout? > --------------------------- > Identifiant de connexion: user1 > Pr?nom: myuser1 > Nom: User1 > Nom complet: myuser1 User1 > Nom affich?: myuser1 User1 > Initiales: MU > R?pertoire utilisateur: /home/user1 > GECOS: myuser1 User1 > Shell de connexion: /bin/sh > Principal Kerberos: User1 at LMSIPA.POLYTECHNIQUE.FR > Adresse courriel: User1 at lmscipa1.lmsipa.polytechnique.fr > UID: 1594400005 > GID: 1594400005 > Mot de passe: True > Membre des groupes: ipausers > Cl?s Kerberos disponibles: False > > Ok, seems to be good... however, if I try kinit : > > # kinit user1 > *kinit: Generic preauthentication failure while getting initial credentials* > > It still does not work. The Kerberos credentials haven't been generated yet. You need to migrate the account either by logging into a system controlled by sssd or go to https://ipa.example.com/ipa/migration/ rob > > Ed > > Le 17/11/2014 19:25, Rob Crittenden a ?crit : >> Edouard Guign? wrote: >>> Hello freeipa users >>> >>> I followed the instructions of this page : >>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>> >>> in order to integrate NIS accounts over IPA with preserving passwords. >>> >>> However, I do not succeed to import user as indicate on documentation : >>> >>> # ipa user-add /user1/--setattr=userpassword={CRYPT}/xxxxxxxxxxxx/ >>> return : >>> *"ipa: ERROR: Constraint violation : invalid password syntax - passwords >>> with storage scheme are not allowed"* >>> >>> Someone could help ? >> You enabled migration mode? >> >> ipa config-mod --enable-migration=true >> >> If you have, what version of IPA is this? >> >> rob >> >> >> > From nadav.mavor at gmail.com Tue Nov 18 16:56:17 2014 From: nadav.mavor at gmail.com (Nadav Mavor) Date: Tue, 18 Nov 2014 11:56:17 -0500 Subject: [Freeipa-users] cloning joined systems In-Reply-To: <75e9bcfb27b14089b9f21950fb7e86eb@BLUPR08MB488.namprd08.prod.outlook.com> References: <75e9bcfb27b14089b9f21950fb7e86eb@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: We doing it all the time just rename the system uninstall IPA client ( do not reboot) and run ipa client installed On Nov 18, 2014 11:47 AM, "Craig White" wrote: > Had a question from one of our engineers. It seems we are a lazy bunch > and have a sometime methodology of using vSphere/vmWare to clone running > virtual machines. > > > > I cannot think of any way to take a virtual machine that has already been > joined to RedHat iDM (freeipa), clone it and then deal with it safely but > is there any supportable way to rename the box, and join it again? > > > > Craig White > > System Administrator > > O 623-201-8179 M 602-377-9752 > > > > [image: cid:image001.png at 01CF86FE.42D51630] > > > > SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: not available URL: From rmj at ast.cam.ac.uk Tue Nov 18 17:57:15 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Tue, 18 Nov 2014 17:57:15 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM Message-ID: <546B887B.5060004@ast.cam.ac.uk> Hi I'm trying to migrate some nis accounts to RHEL 6 IdM while still keeping the original passwords. I followed the instructions at: http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords The passwords are in SHA-512 format and I have been testing the migration with commands like this (generated via a script from my nis passwd file) on my IdM server: $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash --setattr userpassword='{SHA-512}xxxxxxx' where the xxxxxxx is the hashed password from the NIS password file with the leading $6$ stripped off. Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm left with: passwd: files sss and the account that I migrated cannot log in. From the sssd log file (below) it looks like its trying to migrate the password but failing with an LDAP authentication failure. I'd appreciate any pointers to how to find out whats going wrong here. Accounts which I created manually in the web gui are working ok. Thanks Roderick Johnstone Part of sssd log file ===================== (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' as 'working' (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'xxx.xxx.xxx.xxx' as 'working' (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password is missing, starting password migration. (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password migration not possible. (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) [Success] (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] From mail at willsheldon.com Tue Nov 18 18:44:53 2014 From: mail at willsheldon.com (Will Sheldon) Date: Tue, 18 Nov 2014 10:44:53 -0800 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> Message-ID: No, not resolved yet I did test with GSSAPI (-Y) and like you it worked. :( ? Will Sheldon On November 18, 2014 at 8:37:10 AM, dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) wrote: Hi, On Fri, 7 Nov 2014, Dmitri Pal wrote: > On 11/07/2014 01:24 AM, Will Sheldon wrote: >> On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com >> ) wrote: >>> On 11/07/2014 12:18 AM, Will Sheldon wrote: >>>> >>>> On the whole we are loving FreeIPA, Many thanks and much respect to >>>> all involved, we?ve had a great 12-18 months hassle free use out of >>>> it - it is a fantastically stable trouble free solution? however now >>>> we?ve run into a small issue we (as mere mortals) are finding it hard >>>> to resolve :-/ >>>> >>>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything >>>> seems to go well, but one server is behaving oddly. It?s likely not >>>> an IPA issue, it also reset it?s hostname somehow after the upgrade >>>> (it?s an image in an openstack environment) >>>> >>>> If anyone has any pointers as to how to debug I?d be hugely >>>> appreciative :) >>>> >>>> Two servers, server1.domain.com and server2.domain.com >>>> >>>> Server1 can?t push data to server2, there are updates and new records >>>> on server1 that do not exist on server2. >>>> >>>> >>>> from the logs on server1: >>>> >>>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to send >>>> endReplication extended operation (Can't contact LDAP server) >>>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with >>>> GSSAPI auth resumed >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >>>> replicate schema: rc=2 >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to replay >>>> change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will >>>> retry later. >>> >>> Try to see >>> a) Server 1 properly resolves server 2 >>> b) You can connect from server 1 to server 2 using ldapsearch >>> c) your firewall has proper ports open >>> d) dirserver on server 2 is actually running >> >> All seems working: >> >> [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' >> namingContexts > > Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y > switch? is this resolved? I observe it on my systems, too. Exact same symptoms. ldapsearch with "-Y GSSAPI" works. > Did you find anything in the server2 logs? On my "server2", I see "sasl_io_recv failed to decode packet for connection #". Could there be something wrong with default buffer sizes as described in https://bugzilla.redhat.com/show_bug.cgi?id=953653 I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my database is rather small: ~30 users, <10 hosts and services. >> # extended LDIF >> # >> # LDAPv3 >> # base <> with scope baseObject >> # filter: (objectclass=*) >> # requesting: namingContexts >> # >> >> # >> dn: >> namingContexts: dc=domain,dc=com >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> [root at server1 ~]# >> >> And: >> >> [root at server2 ~]# /etc/init.d/dirsrv status >> dirsrv DOMAIN-COM (pid 1009) is running... >> dirsrv PKI-IPA (pid 1083) is running... >> [root at server2 ~]# >> >>> >>> Check logs on server 2 to see whether it actually sees an attempt to >>> connect, I suspect not, so it is most likely a DNS/FW issue or dir server >>> is not running on 2. >>>> >>>> >>>> and the servers: >>>> >>>> [root at server1 ~]# ipa-replica-manage list -v `hostname` >>>> Directory Manager password: >>>> >>>> server2.domain.com: replica >>>> last init status: None >>>> last init ended: None >>>> last update status: 0 Replica acquired successfully: Incremental update >>>> started >>>> last update ended: 2014-11-07 01:35:58+00:00 >>>> [root at server1 ~]# >>>> >>>> >>>> >>>> [root at server2 ~]# ipa-replica-manage list -v `hostname` >>>> Directory Manager password: >>>> >>>> server1.domain.com: replica >>>> last init status: None >>>> last init ended: None >>>> last update status: 0 Replica acquired successfully: Incremental update >>>> succeeded >>>> last update ended: 2014-11-07 01:35:43+00:00 >>>> [root at server2 ~]# Mit freundlichen Gruessen/With best regards, --Daniel. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 18 22:12:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 18 Nov 2014 17:12:12 -0500 Subject: [Freeipa-users] Multiple Domains and SSH In-Reply-To: References: Message-ID: <546BC43C.5070305@redhat.com> On 11/18/2014 01:07 AM, Christoph Kaminski wrote: > Hi > > I can reach each host here via ssh on multiple domains: > > host.mydom.int > host mydom.net > host.mgmt > > sss_ssh_knownhostproxy does work only on the domain which I have use > to register to ipa (mgmt), on the other domains I get ever "The > authenticity of host 'host.mydom.int ()' > can't be established."... why? > And other hosts in those domains are not registered? May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? > it is possible to make it working for the other domains to? > > MfG > Christoph Kaminski > > www.biotronik.com > ------------------------------------------------------------------------ > *BIOTRONIK - excellence for life* > Established with the development of the first German pacemaker in > 1963, BIOTRONIK has upheld the highest quality standards in the fields > of cardiac rhythm management and vascular intervention in more than > 100 countries worldwide. We've developed advanced technologies and > products such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation > (CLS) and Orsiro, the industry's first hybrid drug eluting stent. > BIOTRONIK also offers the broadest portfolio of cardiac devices with > ProMRI?, an advanced technology that gives patients access to magnetic > resonance (MR) scanning. > ------------------------------------------------------------------------ > BIOTRONIK SE & Co. KG > Woermannkehre 1, 12359 Berlin, Germany > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > Vertreten durch ihre Komplement?rin: > BIOTRONIK MT SE > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > ------------------------------------------------------------------------ > This e-mail and the information it contains including attachments are > confidential and meant only for use by the intended recipient(s); > disclosure or copying is strictly prohibited. If you are not > addressed, but in the possession of this e-mail, please notify the > sender immediately and delete the document. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 18 22:17:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 18 Nov 2014 17:17:46 -0500 Subject: [Freeipa-users] Integrating with NIS Domains and Netgroups In-Reply-To: References: Message-ID: <546BC58A.8060702@redhat.com> On 11/18/2014 02:13 AM, Zhong Qiang wrote: > hi, > I have some hosts installed centos4.8/6.5/5.9,and want to > centralize identity/policy/authorization.but ipa client isn't > compatible with centos4.8,so I try to configure FreeIPA integrated > with NIS Domains. > IPAserver:centos7 (+DNS) > nisclient:centos4.8 > ipaclient:centos6.6 > > I followed the instructions of this page: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/nis.html,to > add netgroup(nis_test) and users(zhongq).then configured nis client > installed centos4.8.on the nis client, I could get users data ,look > like that: > > [root at nisclient ~]# getent passwd zhongq > zhongq:*:724800001:724800001:??? ?:/home/zhongq:/bin/sh > > > However,I do not succeed to log into nisclient with zhongq account. > Any ideas? > > Regards, > zhongq > > You need to use some other method for authentication. NIS only supported for identity not for authentication. Use pam_ldap or pam_krb5 for authentication part. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Nov 18 22:19:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 18 Nov 2014 17:19:46 -0500 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546B887B.5060004@ast.cam.ac.uk> References: <546B887B.5060004@ast.cam.ac.uk> Message-ID: <546BC602.5020900@redhat.com> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: > Hi > > I'm trying to migrate some nis accounts to RHEL 6 IdM while still > keeping the original passwords. > > I followed the instructions at: > http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords > > The passwords are in SHA-512 format and I have been testing the > migration with commands like this (generated via a script from my nis > passwd file) on my IdM server: > > $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx > '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash > --setattr userpassword='{SHA-512}xxxxxxx' > > where the xxxxxxx is the hashed password from the NIS password file > with the leading $6$ stripped off. > > Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm > left with: > passwd: files sss > > and the account that I migrated cannot log in. > > From the sssd log file (below) it looks like its trying to migrate the > password but failing with an LDAP authentication failure. > > I'd appreciate any pointers to how to find out whats going wrong here. > > Accounts which I created manually in the web gui are working ok. > > Thanks > > Roderick Johnstone > > Part of sssd log file > ===================== > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' > as 'working' > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [fo_set_port_status] (0x0400): Marking port 0 of duplicate server > 'xxx.xxx.xxx.xxx' as 'working' > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password > is missing, starting password migration. > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] > (0x0100): Executing simple bind as: > uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] > (0x0400): Bind result: Invalid credentials(49), no errmsg set > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password > migration not possible. > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) > [Success] > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] > (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] > [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] > Did you enable migration mode on the IPA server? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rmj at ast.cam.ac.uk Tue Nov 18 22:23:59 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Tue, 18 Nov 2014 22:23:59 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546BC602.5020900@redhat.com> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> Message-ID: <546BC6FF.90106@ast.cam.ac.uk> On 18/11/2014 22:19, Dmitri Pal wrote: > On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >> Hi >> >> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >> keeping the original passwords. >> >> I followed the instructions at: >> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >> >> The passwords are in SHA-512 format and I have been testing the >> migration with commands like this (generated via a script from my nis >> passwd file) on my IdM server: >> >> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >> --setattr userpassword='{SHA-512}xxxxxxx' >> >> where the xxxxxxx is the hashed password from the NIS password file >> with the leading $6$ stripped off. >> >> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >> left with: >> passwd: files sss >> >> and the account that I migrated cannot log in. >> >> From the sssd log file (below) it looks like its trying to migrate the >> password but failing with an LDAP authentication failure. >> >> I'd appreciate any pointers to how to find out whats going wrong here. >> >> Accounts which I created manually in the web gui are working ok. >> >> Thanks >> >> Roderick Johnstone >> >> Part of sssd log file >> ===================== >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >> as 'working' >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >> 'xxx.xxx.xxx.xxx' as 'working' >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >> is missing, starting password migration. >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >> (0x0100): Executing simple bind as: >> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >> (0x0400): Bind result: Invalid credentials(49), no errmsg set >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >> migration not possible. >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >> [Success] >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >> > > Did you enable migration mode on the IPA server? > Yes, I ran: ipa config-mod --enable-migration=true on the IPA server. Roderick From jhrozek at redhat.com Tue Nov 18 22:53:53 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 18 Nov 2014 23:53:53 +0100 Subject: [Freeipa-users] Multiple Domains and SSH In-Reply-To: <546BC43C.5070305@redhat.com> References: <546BC43C.5070305@redhat.com> Message-ID: <126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> > On 18 Nov 2014, at 23:12, Dmitri Pal wrote: > > On 11/18/2014 01:07 AM, Christoph Kaminski wrote: >> Hi >> >> I can reach each host here via ssh on multiple domains: >> >> host.mydom.int >> host mydom.net >> host.mgmt >> >> sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever "The authenticity of host 'host.mydom.int ()' can't be established."... why? >> > > > And other hosts in those domains are not registered? > May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? > Maybe Honza would have some tips for debugging... > >> it is possible to make it working for the other domains to? >> >> MfG >> Christoph Kaminski >> >> www.biotronik.com >> BIOTRONIK - excellence for life >> Established with the development of the first German pacemaker in 1963, BIOTRONIK has upheld the highest quality standards in the fields of cardiac rhythm management and vascular intervention in more than 100 countries worldwide. We?ve developed advanced technologies and products such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI?, an advanced technology that gives patients access to magnetic resonance (MR) scanning. >> BIOTRONIK SE & Co. KG >> Woermannkehre 1, 12359 Berlin, Germany >> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 >> >> Vertreten durch ihre Komplement?rin: >> BIOTRONIK MT SE >> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B >> Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings >> This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 From jhrozek at redhat.com Tue Nov 18 22:56:15 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 18 Nov 2014 23:56:15 +0100 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546BC6FF.90106@ast.cam.ac.uk> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> Message-ID: <1D372499-6F43-4ADE-95F5-AD9E8CAAB9D6@redhat.com> > On 18 Nov 2014, at 23:23, Roderick Johnstone wrote: > > On 18/11/2014 22:19, Dmitri Pal wrote: >> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>> Hi >>> >>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>> keeping the original passwords. >>> >>> I followed the instructions at: >>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>> >>> The passwords are in SHA-512 format and I have been testing the >>> migration with commands like this (generated via a script from my nis >>> passwd file) on my IdM server: >>> >>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>> --setattr userpassword='{SHA-512}xxxxxxx' >>> >>> where the xxxxxxx is the hashed password from the NIS password file >>> with the leading $6$ stripped off. >>> >>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>> left with: >>> passwd: files sss >>> >>> and the account that I migrated cannot log in. >>> >>> From the sssd log file (below) it looks like its trying to migrate the >>> password but failing with an LDAP authentication failure. >>> >>> I'd appreciate any pointers to how to find out whats going wrong here. >>> >>> Accounts which I created manually in the web gui are working ok. >>> >>> Thanks >>> >>> Roderick Johnstone >>> >>> Part of sssd log file >>> ===================== >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>> as 'working' >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>> 'xxx.xxx.xxx.xxx' as 'working' >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >>> is missing, starting password migration. >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>> (0x0100): Executing simple bind as: >>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>> migration not possible. >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>> [Success] >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>> >> >> Did you enable migration mode on the IPA server? >> > > Yes, I ran: > ipa config-mod --enable-migration=true > on the IPA server. > > Roderick Sorry, I missed this thread involved SSSD logs. Normally, error 49 (Invalid credentials) means really a wrong password. Are you sure the password was not mistyped (different keyboard layout or caps lock perhaps) ? Did you try the web UI migration? From rcritten at redhat.com Tue Nov 18 22:58:07 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Nov 2014 17:58:07 -0500 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546BC6FF.90106@ast.cam.ac.uk> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> Message-ID: <546BCEFF.9080806@redhat.com> Roderick Johnstone wrote: > On 18/11/2014 22:19, Dmitri Pal wrote: >> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>> Hi >>> >>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>> keeping the original passwords. >>> >>> I followed the instructions at: >>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>> >>> The passwords are in SHA-512 format and I have been testing the >>> migration with commands like this (generated via a script from my nis >>> passwd file) on my IdM server: >>> >>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>> --setattr userpassword='{SHA-512}xxxxxxx' >>> >>> where the xxxxxxx is the hashed password from the NIS password file >>> with the leading $6$ stripped off. >>> >>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>> left with: >>> passwd: files sss >>> >>> and the account that I migrated cannot log in. >>> >>> From the sssd log file (below) it looks like its trying to migrate the >>> password but failing with an LDAP authentication failure. >>> >>> I'd appreciate any pointers to how to find out whats going wrong here. >>> >>> Accounts which I created manually in the web gui are working ok. >>> >>> Thanks >>> >>> Roderick Johnstone >>> >>> Part of sssd log file >>> ===================== >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>> as 'working' >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>> 'xxx.xxx.xxx.xxx' as 'working' >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >>> is missing, starting password migration. >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>> (0x0100): Executing simple bind as: >>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>> migration not possible. >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>> [Success] >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>> >> >> Did you enable migration mode on the IPA server? >> > > Yes, I ran: > ipa config-mod --enable-migration=true > on the IPA server. > > Roderick > The has name probably needs to match something in cn=Password Storage Schemes,cn=plugins,cn=config. I'd try either {SHA512} or {SSHA512} and see if one of those works better. rob From jcholast at redhat.com Wed Nov 19 06:51:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 07:51:46 +0100 Subject: [Freeipa-users] Multiple Domains and SSH In-Reply-To: <126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> References: <546BC43C.5070305@redhat.com> <126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> Message-ID: <546C3E02.9020804@redhat.com> Hi, Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): > >> On 18 Nov 2014, at 23:12, Dmitri Pal wrote: >> >> On 11/18/2014 01:07 AM, Christoph Kaminski wrote: >>> Hi >>> >>> I can reach each host here via ssh on multiple domains: >>> >>> host.mydom.int >>> host mydom.net >>> host.mgmt >>> >>> sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever "The authenticity of host 'host.mydom.int ()' can't be established."... why? Because it does not know that the hostnames refer to the same host. Do you have a reverse DNS record set up for the host? Does it point to the same hostname that you used to register the host in IPA? >>> >> >> >> And other hosts in those domains are not registered? >> May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? This would work too. >> > > Maybe Honza would have some tips for debugging... See pages 13-16 of . Honza -- Jan Cholasta From rmj at ast.cam.ac.uk Wed Nov 19 08:07:02 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Wed, 19 Nov 2014 08:07:02 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <1D372499-6F43-4ADE-95F5-AD9E8CAAB9D6@redhat.com> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <1D372499-6F43-4ADE-95F5-AD9E8CAAB9D6@redhat.com> Message-ID: <546C4FA6.90109@ast.cam.ac.uk> On 18/11/2014 22:56, Jakub Hrozek wrote: > >> On 18 Nov 2014, at 23:23, Roderick Johnstone wrote: >> >> On 18/11/2014 22:19, Dmitri Pal wrote: >>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>> Hi >>>> >>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>> keeping the original passwords. >>>> >>>> I followed the instructions at: >>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>> >>>> The passwords are in SHA-512 format and I have been testing the >>>> migration with commands like this (generated via a script from my nis >>>> passwd file) on my IdM server: >>>> >>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>> >>>> where the xxxxxxx is the hashed password from the NIS password file >>>> with the leading $6$ stripped off. >>>> >>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>> left with: >>>> passwd: files sss >>>> >>>> and the account that I migrated cannot log in. >>>> >>>> From the sssd log file (below) it looks like its trying to migrate the >>>> password but failing with an LDAP authentication failure. >>>> >>>> I'd appreciate any pointers to how to find out whats going wrong here. >>>> >>>> Accounts which I created manually in the web gui are working ok. >>>> >>>> Thanks >>>> >>>> Roderick Johnstone >>>> >>>> Part of sssd log file >>>> ===================== >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>> as 'working' >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>> 'xxx.xxx.xxx.xxx' as 'working' >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >>>> is missing, starting password migration. >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>> (0x0100): Executing simple bind as: >>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>> migration not possible. >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>> [Success] >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>> >>> >>> Did you enable migration mode on the IPA server? >>> >> >> Yes, I ran: >> ipa config-mod --enable-migration=true >> on the IPA server. >> >> Roderick > > Sorry, I missed this thread involved SSSD logs. > > Normally, error 49 (Invalid credentials) means really a wrong password. Are you sure the password was not mistyped (different keyboard layout or caps lock perhaps) ? > Definitely not mistyped. I have tried lots of times. Also tried typing the password in as username to check that each character echos as expected, so pretty sure its not key layout issue. > Did you try the web UI migration? Not yet. I'll see if I can find some docs on how to do that. > From rmj at ast.cam.ac.uk Wed Nov 19 08:33:12 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Wed, 19 Nov 2014 08:33:12 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546BCEFF.9080806@redhat.com> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <546BCEFF.9080806@redhat.com> Message-ID: <546C55C8.1020106@ast.cam.ac.uk> On 18/11/2014 22:58, Rob Crittenden wrote: > Roderick Johnstone wrote: >> On 18/11/2014 22:19, Dmitri Pal wrote: >>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>> Hi >>>> >>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>> keeping the original passwords. >>>> >>>> I followed the instructions at: >>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>> >>>> The passwords are in SHA-512 format and I have been testing the >>>> migration with commands like this (generated via a script from my nis >>>> passwd file) on my IdM server: >>>> >>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>> >>>> where the xxxxxxx is the hashed password from the NIS password file >>>> with the leading $6$ stripped off. >>>> >>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>> left with: >>>> passwd: files sss >>>> >>>> and the account that I migrated cannot log in. >>>> >>>> From the sssd log file (below) it looks like its trying to migrate the >>>> password but failing with an LDAP authentication failure. >>>> >>>> I'd appreciate any pointers to how to find out whats going wrong here. >>>> >>>> Accounts which I created manually in the web gui are working ok. >>>> >>>> Thanks >>>> >>>> Roderick Johnstone >>>> >>>> Part of sssd log file >>>> ===================== >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>> as 'working' >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>> 'xxx.xxx.xxx.xxx' as 'working' >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >>>> is missing, starting password migration. >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>> (0x0100): Executing simple bind as: >>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>> migration not possible. >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>> [Success] >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>> >>> >>> Did you enable migration mode on the IPA server? >>> >> >> Yes, I ran: >> ipa config-mod --enable-migration=true >> on the IPA server. >> >> Roderick >> > > The has name probably needs to match something in cn=Password Storage > Schemes,cn=plugins,cn=config. > > I'd try either {SHA512} or {SSHA512} and see if one of those works better. > > rob > Rob I had wondered about the specification of the password hash type. I chose SHA-512 as it seemed to be suggested in the passwordStorageScheme attribute described in Table 14.1 of the Redhat Directory Server Admin Guide, https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html. But now I come to re-read that doc it suggests perhaps that SHA covers all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as the userpassword specification. I have also seen the userpassword attribute referred to in other places as userPassword and wondered whether the attribute name is case sensitive. Do you know? Thanks for your input. Roderick From tbordaz at redhat.com Wed Nov 19 08:49:31 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 19 Nov 2014 09:49:31 +0100 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> Message-ID: <546C599B.9090101@redhat.com> On 11/18/2014 07:44 PM, Will Sheldon wrote: > > No, not resolved yet I did test with GSSAPI (-Y) and like you it > worked. :( Hello, Would it be possible to get server1/server2 logs (error/access) and config (dse.ldif) ?. Turning on replication logs would help ( http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting). In the sample of the log, there is a failure while ending a replication session. No replication error before ? It is like suddenly server1 was no longer able to reach server2 (dns or network issue ?). thanks thierry > > > Will Sheldon > > On November 18, 2014 at 8:37:10 AM, dbischof at hrz.uni-kassel.de > (dbischof at hrz.uni-kassel.de ) wrote: > >> Hi, >> >> On Fri, 7 Nov 2014, Dmitri Pal wrote: >> >> > On 11/07/2014 01:24 AM, Will Sheldon wrote: >> >> On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com >> >> ) wrote: >> >>> On 11/07/2014 12:18 AM, Will Sheldon wrote: >> >>>> >> >>>> On the whole we are loving FreeIPA, Many thanks and much respect to >> >>>> all involved, we've had a great 12-18 months hassle free use out of >> >>>> it - it is a fantastically stable trouble free solution... >> however now >> >>>> we've run into a small issue we (as mere mortals) are finding it >> hard >> >>>> to resolve :-/ >> >>>> >> >>>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything >> >>>> seems to go well, but one server is behaving oddly. It's likely not >> >>>> an IPA issue, it also reset it's hostname somehow after the upgrade >> >>>> (it's an image in an openstack environment) >> >>>> >> >>>> If anyone has any pointers as to how to debug I'd be hugely >> >>>> appreciative :) >> >>>> >> >>>> Two servers, server1.domain.com and server2.domain.com >> >>>> >> >>>> Server1 can't push data to server2, there are updates and new >> records >> >>>> on server1 that do not exist on server2. >> >>>> >> >>>> >> >>>> from the logs on server1: >> >>>> >> >>>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - >> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable >> to send >> >>>> endReplication extended operation (Can't contact LDAP server) >> >>>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - >> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Replication bind >> with >> >>>> GSSAPI auth resumed >> >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >> >>>> replicate schema: rc=2 >> >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed >> to replay >> >>>> change (uniqueid (null), CSN (null)): Can't contact LDAP >> server(-1). Will >> >>>> retry later. >> >>> >> >>> Try to see >> >>> a) Server 1 properly resolves server 2 >> >>> b) You can connect from server 1 to server 2 using ldapsearch >> >>> c) your firewall has proper ports open >> >>> d) dirserver on server 2 is actually running >> >> >> >> All seems working: >> >> >> >> [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s >> base -b '' >> >> namingContexts >> > >> > Can you try kinit admin and then use kerberos GSSAPI to connect, >> i.e. -Y >> > switch? >> >> is this resolved? I observe it on my systems, too. Exact same symptoms. >> ldapsearch with "-Y GSSAPI" works. >> >> > Did you find anything in the server2 logs? >> >> On my "server2", I see "sasl_io_recv failed to decode packet for >> connection #". >> >> Could there be something wrong with default buffer sizes as described in >> https://bugzilla.redhat.com/show_bug.cgi?id=953653 >> >> I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my >> database is rather small: ~30 users, <10 hosts and services. >> >> >> # extended LDIF >> >> # >> >> # LDAPv3 >> >> # base <> with scope baseObject >> >> # filter: (objectclass=*) >> >> # requesting: namingContexts >> >> # >> >> >> >> # >> >> dn: >> >> namingContexts: dc=domain,dc=com >> >> >> >> # search result >> >> search: 2 >> >> result: 0 Success >> >> >> >> # numResponses: 2 >> >> # numEntries: 1 >> >> [root at server1 ~]# >> >> >> >> And: >> >> >> >> [root at server2 ~]# /etc/init.d/dirsrv status >> >> dirsrv DOMAIN-COM (pid 1009) is running... >> >> dirsrv PKI-IPA (pid 1083) is running... >> >> [root at server2 ~]# >> >> >> >>> >> >>> Check logs on server 2 to see whether it actually sees an attempt to >> >>> connect, I suspect not, so it is most likely a DNS/FW issue or >> dir server >> >>> is not running on 2. >> >>>> >> >>>> >> >>>> and the servers: >> >>>> >> >>>> [root at server1 ~]# ipa-replica-manage list -v `hostname` >> >>>> Directory Manager password: >> >>>> >> >>>> server2.domain.com: replica >> >>>> last init status: None >> >>>> last init ended: None >> >>>> last update status: 0 Replica acquired successfully: Incremental >> update >> >>>> started >> >>>> last update ended: 2014-11-07 01:35:58+00:00 >> >>>> [root at server1 ~]# >> >>>> >> >>>> >> >>>> >> >>>> [root at server2 ~]# ipa-replica-manage list -v `hostname` >> >>>> Directory Manager password: >> >>>> >> >>>> server1.domain.com: replica >> >>>> last init status: None >> >>>> last init ended: None >> >>>> last update status: 0 Replica acquired successfully: Incremental >> update >> >>>> succeeded >> >>>> last update ended: 2014-11-07 01:35:43+00:00 >> >>>> [root at server2 ~]# >> >> >> Mit freundlichen Gruessen/With best regards, >> >> --Daniel. >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmj at ast.cam.ac.uk Wed Nov 19 10:22:34 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Wed, 19 Nov 2014 10:22:34 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546C55C8.1020106@ast.cam.ac.uk> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <546BCEFF.9080806@redhat.com> <546C55C8.1020106@ast.cam.ac.uk> Message-ID: <546C6F6A.3050308@ast.cam.ac.uk> On 19/11/2014 08:33, Roderick Johnstone wrote: > On 18/11/2014 22:58, Rob Crittenden wrote: >> Roderick Johnstone wrote: >>> On 18/11/2014 22:19, Dmitri Pal wrote: >>>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>>> Hi >>>>> >>>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>>> keeping the original passwords. >>>>> >>>>> I followed the instructions at: >>>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>>> >>>>> >>>>> The passwords are in SHA-512 format and I have been testing the >>>>> migration with commands like this (generated via a script from my nis >>>>> passwd file) on my IdM server: >>>>> >>>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx --uid=xxxx >>>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>>> >>>>> where the xxxxxxx is the hashed password from the NIS password file >>>>> with the leading $6$ stripped off. >>>>> >>>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>>> left with: >>>>> passwd: files sss >>>>> >>>>> and the account that I migrated cannot log in. >>>>> >>>>> From the sssd log file (below) it looks like its trying to migrate >>>>> the >>>>> password but failing with an LDAP authentication failure. >>>>> >>>>> I'd appreciate any pointers to how to find out whats going wrong here. >>>>> >>>>> Accounts which I created manually in the web gui are working ok. >>>>> >>>>> Thanks >>>>> >>>>> Roderick Johnstone >>>>> >>>>> Part of sssd log file >>>>> ===================== >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>>> as 'working' >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>>> 'xxx.xxx.xxx.xxx' as 'working' >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password >>>>> is missing, starting password migration. >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>>> (0x0100): Executing simple bind as: >>>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>>> migration not possible. >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>>> [Success] >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>>> >>>> >>>> Did you enable migration mode on the IPA server? >>>> >>> >>> Yes, I ran: >>> ipa config-mod --enable-migration=true >>> on the IPA server. >>> >>> Roderick >>> >> >> The has name probably needs to match something in cn=Password Storage >> Schemes,cn=plugins,cn=config. >> >> I'd try either {SHA512} or {SSHA512} and see if one of those works >> better. >> >> rob >> > > Rob > > I had wondered about the specification of the password hash type. > > I chose SHA-512 as it seemed to be suggested in the > passwordStorageScheme attribute described in Table 14.1 of the Redhat > Directory Server Admin Guide, > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html. > But now I come to re-read that doc it suggests perhaps that SHA covers > all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as > the userpassword specification. > > I have also seen the userpassword attribute referred to in other places > as userPassword and wondered whether the attribute name is case > sensitive. Do you know? > > Thanks for your input. > > Roderick > Rob I just tried with --setattr userpassword='{SHA}xxxxxxx' but I get the same result: [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password migration not possible. I'm wondering if its something to do with the quoting. The hashed password contains $ and there are the {} around the SHA so I'm using strong single quotes to prevent anything following the $ being interpreted as a variable, I hope. Maybe this is a ref herring. Roderick Roderick From xiaoqiang3243 at gmail.com Wed Nov 19 10:25:56 2014 From: xiaoqiang3243 at gmail.com (Zhong Qiang) Date: Wed, 19 Nov 2014 18:25:56 +0800 Subject: [Freeipa-users] Integrating with NIS Domains and Netgroups In-Reply-To: <546BC58A.8060702@redhat.com> References: <546BC58A.8060702@redhat.com> Message-ID: thank you, It is work by using ldap+krb5 (nisclient:centos4.8).By the way, Is it possible to enroll nisclient ? And how to do this?And how to carry out HBAC RULES for nisclient?I try to use WebUI,but i am not succeed,look like this: Enrollment Kerberos Key: Kerberos Key Not Present One-Time-Password: One-Time-Password Not Present ------------------------------ Host Certificate Status: *No Valid Certificate* regards, zhongq 2014-11-19 6:17 GMT+08:00 Dmitri Pal : > On 11/18/2014 02:13 AM, Zhong Qiang wrote: > > hi, > I have some hosts installed centos4.8/6.5/5.9,and want to centralize > identity/policy/authorization.but ipa client isn't compatible with > centos4.8,so I try to configure FreeIPA integrated with NIS Domains. > IPAserver:centos7 (+DNS) > nisclient:centos4.8 > ipaclient:centos6.6 > > I followed the instructions of this page: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/nis.html,to > add netgroup(nis_test) and users(zhongq).then configured nis client > installed centos4.8.on the nis client, I could get users data ,look like > that: > > [root at nisclient ~]# getent passwd zhongq > zhongq:*:724800001:724800001:??? ?:/home/zhongq:/bin/sh > > > However,I do not succeed to log into nisclient with zhongq account. > Any ideas? > > Regards, > zhongq > > > You need to use some other method for authentication. NIS only supported > for identity not for authentication. Use pam_ldap or pam_krb5 for > authentication part. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Wed Nov 19 10:37:43 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 19 Nov 2014 11:37:43 +0100 Subject: [Freeipa-users] freeipa-server from copr repo Message-ID: <546C72F7.1050507@martos.bme.hu> hi All, --> Finished Dependency Resolution Error: Package: freeipa-server-4.1.1-1.1.el7.centos.x86_64 (mkosek-freeipa) Requires: pki-ca >= 10.2.0-3 Available: pki-ca-10.0.5-3.el7.noarch (base) pki-ca = 10.0.5-3.el7 Available: pki-ca-10.1.2-3.el7.centos.noarch (mkosek-freeipa) pki-ca = 10.1.2-3.el7.centos You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Ho can I fix this? 10x tamas From mkosek at redhat.com Wed Nov 19 10:54:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 11:54:35 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546C72F7.1050507@martos.bme.hu> References: <546C72F7.1050507@martos.bme.hu> Message-ID: <546C76EB.9070707@redhat.com> On 11/19/2014 11:37 AM, Tamas Papp wrote: > hi All, > > --> Finished Dependency Resolution > Error: Package: freeipa-server-4.1.1-1.1.el7.centos.x86_64 (mkosek-freeipa) > Requires: pki-ca >= 10.2.0-3 > Available: pki-ca-10.0.5-3.el7.noarch (base) > pki-ca = 10.0.5-3.el7 > Available: pki-ca-10.1.2-3.el7.centos.noarch (mkosek-freeipa) > pki-ca = 10.1.2-3.el7.centos > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest We are working on a fix right now. So hopefully, the fixed CentOS repo would be available during today. > Ho can I fix this? Waiting a bit and then trying to install again :-) > > 10x > tamas > From tompos at martos.bme.hu Wed Nov 19 10:57:30 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 19 Nov 2014 11:57:30 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546C76EB.9070707@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> Message-ID: <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> I am good in waiting;) Thanks for the prompt reply. -- Sent from mobile On November 19, 2014 11:54:40 AM Martin Kosek wrote: > On 11/19/2014 11:37 AM, Tamas Papp wrote: > > hi All, > > > > --> Finished Dependency Resolution > > Error: Package: freeipa-server-4.1.1-1.1.el7.centos.x86_64 (mkosek-freeipa) > > Requires: pki-ca >= 10.2.0-3 > > Available: pki-ca-10.0.5-3.el7.noarch (base) > > pki-ca = 10.0.5-3.el7 > > Available: pki-ca-10.1.2-3.el7.centos.noarch (mkosek-freeipa) > > pki-ca = 10.1.2-3.el7.centos > > You could try using --skip-broken to work around the problem > > You could try running: rpm -Va --nofiles --nodigest > > We are working on a fix right now. So hopefully, the fixed CentOS repo would be > available during today. > > > Ho can I fix this? > > Waiting a bit and then trying to install again :-) > > > > > 10x > > tamas > > > From dpal at redhat.com Wed Nov 19 13:19:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Nov 2014 08:19:14 -0500 Subject: [Freeipa-users] Integrating with NIS Domains and Netgroups In-Reply-To: References: <546BC58A.8060702@redhat.com> Message-ID: <546C98D2.8070309@redhat.com> On 11/19/2014 05:25 AM, Zhong Qiang wrote: > thank you, > It is work by using ldap+krb5 (nisclient:centos4.8).By the way, Is it > possible to enroll nisclient ? And how to do this?And how to carry out > HBAC RULES for nisclient?I try to use WebUI,but i am not succeed,look Only SSSD understands IPA HBAC. We have CentOS 7 nowadays and 7.1 is on the way so 4.8 is very old and your options will be very limited. > like this: > > > Enrollment > > > Kerberos Key: > Kerberos Key Not Present > One-Time-Password: > One-Time-Password Not Present > > ------------------------------------------------------------------------ > > > Host Certificate > > > Status: > *No Valid Certificate* > > > regards, > zhongq > > 2014-11-19 6:17 GMT+08:00 Dmitri Pal >: > > On 11/18/2014 02:13 AM, Zhong Qiang wrote: >> hi, >> I have some hosts installed centos4.8/6.5/5.9,and want to >> centralize identity/policy/authorization.but ipa client isn't >> compatible with centos4.8,so I try to configure FreeIPA >> integrated with NIS Domains. >> IPAserver:centos7 (+DNS) >> nisclient:centos4.8 >> ipaclient:centos6.6 >> >> I followed the instructions of this page: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/nis.html,to >> add netgroup(nis_test) and users(zhongq).then configured nis >> client installed centos4.8.on the nis client, I could get users >> data ,look like that: >> >> [root at nisclient ~]# getent passwd zhongq >> zhongq:*:724800001:724800001:??? ?:/home/zhongq:/bin/sh >> >> >> However,I do not succeed to log into nisclient with zhongq account. >> Any ideas? >> >> Regards, >> zhongq >> >> > You need to use some other method for authentication. NIS only > supported for identity not for authentication. Use pam_ldap or > pam_krb5 for authentication part. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > 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 > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 19 14:53:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Nov 2014 09:53:18 -0500 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546C6F6A.3050308@ast.cam.ac.uk> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <546BCEFF.9080806@redhat.com> <546C55C8.1020106@ast.cam.ac.uk> <546C6F6A.3050308@ast.cam.ac.uk> Message-ID: <546CAEDE.6050702@redhat.com> Roderick Johnstone wrote: > On 19/11/2014 08:33, Roderick Johnstone wrote: >> On 18/11/2014 22:58, Rob Crittenden wrote: >>> Roderick Johnstone wrote: >>>> On 18/11/2014 22:19, Dmitri Pal wrote: >>>>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>>>> Hi >>>>>> >>>>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>>>> keeping the original passwords. >>>>>> >>>>>> I followed the instructions at: >>>>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>>>> >>>>>> >>>>>> >>>>>> The passwords are in SHA-512 format and I have been testing the >>>>>> migration with commands like this (generated via a script from my nis >>>>>> passwd file) on my IdM server: >>>>>> >>>>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx >>>>>> --uid=xxxx >>>>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>>>> >>>>>> where the xxxxxxx is the hashed password from the NIS password file >>>>>> with the leading $6$ stripped off. >>>>>> >>>>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>>>> left with: >>>>>> passwd: files sss >>>>>> >>>>>> and the account that I migrated cannot log in. >>>>>> >>>>>> From the sssd log file (below) it looks like its trying to migrate >>>>>> the >>>>>> password but failing with an LDAP authentication failure. >>>>>> >>>>>> I'd appreciate any pointers to how to find out whats going wrong >>>>>> here. >>>>>> >>>>>> Accounts which I created manually in the web gui are working ok. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Roderick Johnstone >>>>>> >>>>>> Part of sssd log file >>>>>> ===================== >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>>>> as 'working' >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>>>> 'xxx.xxx.xxx.xxx' as 'working' >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos >>>>>> password >>>>>> is missing, starting password migration. >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>>>> (0x0100): Executing simple bind as: >>>>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>>>> migration not possible. >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>>>> [Success] >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>>>> >>>>> >>>>> Did you enable migration mode on the IPA server? >>>>> >>>> >>>> Yes, I ran: >>>> ipa config-mod --enable-migration=true >>>> on the IPA server. >>>> >>>> Roderick >>>> >>> >>> The has name probably needs to match something in cn=Password Storage >>> Schemes,cn=plugins,cn=config. >>> >>> I'd try either {SHA512} or {SSHA512} and see if one of those works >>> better. >>> >>> rob >>> >> >> Rob >> >> I had wondered about the specification of the password hash type. >> >> I chose SHA-512 as it seemed to be suggested in the >> passwordStorageScheme attribute described in Table 14.1 of the Redhat >> Directory Server Admin Guide, >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html. >> >> But now I come to re-read that doc it suggests perhaps that SHA covers >> all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as >> the userpassword specification. >> >> I have also seen the userpassword attribute referred to in other places >> as userPassword and wondered whether the attribute name is case >> sensitive. Do you know? >> >> Thanks for your input. >> >> Roderick >> > > Rob > > I just tried with --setattr userpassword='{SHA}xxxxxxx' but I get the > same result: > [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no > errmsg set > [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password > migration not possible. > > I'm wondering if its something to do with the quoting. The hashed > password contains $ and there are the {} around the SHA so I'm using > strong single quotes to prevent anything following the $ being > interpreted as a variable, I hope. Maybe this is a ref herring. > I think your quoting is correct. I've only used this method with crypt passwords. I guess theoretically it should work with other crypt(3) schemes but I've never tried. There could be some 389-ds-specific gotchas. Crypt defines the storage as $id$salt$encrypted so perhaps strip out the $id$ part since that is being defined by {SHA}, but I'm really only guessing. The 389-ds guys may know. LDAP attributes are not case sensitive. rob From rcritten at redhat.com Wed Nov 19 15:00:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Nov 2014 10:00:13 -0500 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546CAEDE.6050702@redhat.com> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <546BCEFF.9080806@redhat.com> <546C55C8.1020106@ast.cam.ac.uk> <546C6F6A.3050308@ast.cam.ac.uk> <546CAEDE.6050702@redhat.com> Message-ID: <546CB07D.1040106@redhat.com> Rob Crittenden wrote: > Roderick Johnstone wrote: >> On 19/11/2014 08:33, Roderick Johnstone wrote: >>> On 18/11/2014 22:58, Rob Crittenden wrote: >>>> Roderick Johnstone wrote: >>>>> On 18/11/2014 22:19, Dmitri Pal wrote: >>>>>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>>>>> Hi >>>>>>> >>>>>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>>>>> keeping the original passwords. >>>>>>> >>>>>>> I followed the instructions at: >>>>>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>>>>> >>>>>>> >>>>>>> >>>>>>> The passwords are in SHA-512 format and I have been testing the >>>>>>> migration with commands like this (generated via a script from my nis >>>>>>> passwd file) on my IdM server: >>>>>>> >>>>>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx >>>>>>> --uid=xxxx >>>>>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>>>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>>>>> >>>>>>> where the xxxxxxx is the hashed password from the NIS password file >>>>>>> with the leading $6$ stripped off. >>>>>>> >>>>>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>>>>> left with: >>>>>>> passwd: files sss >>>>>>> >>>>>>> and the account that I migrated cannot log in. >>>>>>> >>>>>>> From the sssd log file (below) it looks like its trying to migrate >>>>>>> the >>>>>>> password but failing with an LDAP authentication failure. >>>>>>> >>>>>>> I'd appreciate any pointers to how to find out whats going wrong >>>>>>> here. >>>>>>> >>>>>>> Accounts which I created manually in the web gui are working ok. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Roderick Johnstone >>>>>>> >>>>>>> Part of sssd log file >>>>>>> ===================== >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>>>>> as 'working' >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>>>>> 'xxx.xxx.xxx.xxx' as 'working' >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos >>>>>>> password >>>>>>> is missing, starting password migration. >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>>>>> (0x0100): Executing simple bind as: >>>>>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>>>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>>>>> migration not possible. >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>>>>> [Success] >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>>>>> >>>>>> >>>>>> Did you enable migration mode on the IPA server? >>>>>> >>>>> >>>>> Yes, I ran: >>>>> ipa config-mod --enable-migration=true >>>>> on the IPA server. >>>>> >>>>> Roderick >>>>> >>>> >>>> The has name probably needs to match something in cn=Password Storage >>>> Schemes,cn=plugins,cn=config. >>>> >>>> I'd try either {SHA512} or {SSHA512} and see if one of those works >>>> better. >>>> >>>> rob >>>> >>> >>> Rob >>> >>> I had wondered about the specification of the password hash type. >>> >>> I chose SHA-512 as it seemed to be suggested in the >>> passwordStorageScheme attribute described in Table 14.1 of the Redhat >>> Directory Server Admin Guide, >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html. >>> >>> But now I come to re-read that doc it suggests perhaps that SHA covers >>> all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as >>> the userpassword specification. >>> >>> I have also seen the userpassword attribute referred to in other places >>> as userPassword and wondered whether the attribute name is case >>> sensitive. Do you know? >>> >>> Thanks for your input. >>> >>> Roderick >>> >> >> Rob >> >> I just tried with --setattr userpassword='{SHA}xxxxxxx' but I get the >> same result: >> [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no >> errmsg set >> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >> migration not possible. >> >> I'm wondering if its something to do with the quoting. The hashed >> password contains $ and there are the {} around the SHA so I'm using >> strong single quotes to prevent anything following the $ being >> interpreted as a variable, I hope. Maybe this is a ref herring. >> > > I think your quoting is correct. > > I've only used this method with crypt passwords. I guess theoretically > it should work with other crypt(3) schemes but I've never tried. There > could be some 389-ds-specific gotchas. > > Crypt defines the storage as $id$salt$encrypted so perhaps strip out the > $id$ part since that is being defined by {SHA}, but I'm really only > guessing. The 389-ds guys may know. > > LDAP attributes are not case sensitive. Ok, this question was bugging me so I took a second to look into it. The trick is to use CRYPT and not be too clever about knowing the scheme the password is stored in. This worked for me: # grep myuser /etc/shadow $ ipa user-add --first=test --last=user --setattr userpassword='{CRYPT}$6$blahblah$moregibberish' testuser $ ldapsearch -x -D 'uid=testuser,cn=users,cn=accounts,dc=example,dc=com' -W Enter LDAP Password: rob From mkosek at redhat.com Wed Nov 19 16:23:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 17:23:28 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> Message-ID: <546CC400.3060902@redhat.com> On 11/19/2014 11:57 AM, Tamas Papp wrote: > I am good in waiting;) > > Thanks for the prompt reply. Ok Tamas, I think we *finally* got somewhere. Can you please try the mkosek/freeipa Copr repo now? I was able to install upstream "freeipa-server" 4.1.1 package on my RHEL-7.0 machine (should be the same for CentOS) and run ipa-server-install: # yum install freeipa-server --enablerepo=mkosek-freeipa ... Resolving Dependencies --> Running transaction check ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be installed ... Transaction Summary ======================================================================================================== Install 1 Package (+338 Dependent packages) Upgrade ( 11 Dependent packages) Total download size: 146 M ... # rpm -q freeipa-server freeipa-server-4.1.1-1.2.el7.centos.x86_64 # ipa-server-install --setup-dns # kinit admin Password for admin at EXAMPLE.COM: Thanks, Martin From bill at pecknet.com Wed Nov 19 16:34:10 2014 From: bill at pecknet.com (Bill Peck) Date: Wed, 19 Nov 2014 11:34:10 -0500 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546CC400.3060902@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> Message-ID: Hi Marin, I was able to install from the copr repo now as well. Thank you! However I wasn't able to finish the install: [23/27]: configure certmonger for renewals [24/27]: configure certificate renewals [error] DBusException: org.fedorahosted.certmonger.bad_arg: The location "/etc/pki/pki-tomcat/alias" could not be accessed due to insufficient permissions. Don't know if you need the command for how I was installing ipa. But here is the line from my anseible playbook. shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername }} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns --forwarder={{ dnsforwarder }} -U creates={{ slapd }} On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek wrote: > On 11/19/2014 11:57 AM, Tamas Papp wrote: > > I am good in waiting;) > > > > Thanks for the prompt reply. > > Ok Tamas, I think we *finally* got somewhere. Can you please try the > mkosek/freeipa Copr repo now? > > I was able to install upstream "freeipa-server" 4.1.1 package on my > RHEL-7.0 > machine (should be the same for CentOS) and run ipa-server-install: > > # yum install freeipa-server --enablerepo=mkosek-freeipa > ... > Resolving Dependencies > --> Running transaction check > ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be installed > ... > Transaction Summary > > ======================================================================================================== > Install 1 Package (+338 Dependent packages) > Upgrade ( 11 Dependent packages) > > Total download size: 146 M > ... > > # rpm -q freeipa-server > freeipa-server-4.1.1-1.2.el7.centos.x86_64 > > # ipa-server-install --setup-dns > > # kinit admin > Password for admin at EXAMPLE.COM: > > Thanks, > Martin > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Nov 19 16:41:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 11:41:12 -0500 (EST) Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> Message-ID: <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> It is highly probable the issue is caused by SELinux (check for AVCs in /var/log/audit/audit.log). Can you try with SELinux permissive? We specifically did not build selinux-policy as we do not think we should be the ones maintaining it for CentOS. HTH, Martin ----- Original Message ----- > From: "Bill Peck" > To: "Martin Kosek" > Cc: "Tamas Papp" , freeipa-users at redhat.com > Sent: Wednesday, November 19, 2014 5:34:10 PM > Subject: Re: [Freeipa-users] freeipa-server from copr repo > > Hi Marin, > > I was able to install from the copr repo now as well. Thank you! > > However I wasn't able to finish the install: > > [23/27]: configure certmonger for renewals > [24/27]: configure certificate renewals > [error] DBusException: org.fedorahosted.certmonger.bad_arg: The location > "/etc/pki/pki-tomcat/alias" could not be accessed due to insufficient > permissions. > > > Don't know if you need the command for how I was installing ipa. But here > is the line from my anseible playbook. > shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername > }} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns > --forwarder={{ dnsforwarder }} -U creates={{ slapd }} > > On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek wrote: > > > On 11/19/2014 11:57 AM, Tamas Papp wrote: > > > I am good in waiting;) > > > > > > Thanks for the prompt reply. > > > > Ok Tamas, I think we *finally* got somewhere. Can you please try the > > mkosek/freeipa Copr repo now? > > > > I was able to install upstream "freeipa-server" 4.1.1 package on my > > RHEL-7.0 > > machine (should be the same for CentOS) and run ipa-server-install: > > > > # yum install freeipa-server --enablerepo=mkosek-freeipa > > ... > > Resolving Dependencies > > --> Running transaction check > > ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be installed > > ... > > Transaction Summary > > > > ======================================================================================================== > > Install 1 Package (+338 Dependent packages) > > Upgrade ( 11 Dependent packages) > > > > Total download size: 146 M > > ... > > > > # rpm -q freeipa-server > > freeipa-server-4.1.1-1.2.el7.centos.x86_64 > > > > # ipa-server-install --setup-dns > > > > # kinit admin > > Password for admin at EXAMPLE.COM: > > > > Thanks, > > Martin > > > > -- > > 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 > > > From bill at pecknet.com Wed Nov 19 16:56:21 2014 From: bill at pecknet.com (Bill Peck) Date: Wed, 19 Nov 2014 11:56:21 -0500 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> Message-ID: Hi Martin, Yes, setting selinux to permissive allowed me to install and configure IPA 4.1 on CentOS 7. :-) On Wed, Nov 19, 2014 at 11:41 AM, Martin Kosek wrote: > It is highly probable the issue is caused by SELinux (check for AVCs in > /var/log/audit/audit.log). > > Can you try with SELinux permissive? We specifically did not build > selinux-policy as we do not think we should be the ones maintaining it for > CentOS. > > HTH, > Martin > > ----- Original Message ----- > > From: "Bill Peck" > > To: "Martin Kosek" > > Cc: "Tamas Papp" , freeipa-users at redhat.com > > Sent: Wednesday, November 19, 2014 5:34:10 PM > > Subject: Re: [Freeipa-users] freeipa-server from copr repo > > > > Hi Marin, > > > > I was able to install from the copr repo now as well. Thank you! > > > > However I wasn't able to finish the install: > > > > [23/27]: configure certmonger for renewals > > [24/27]: configure certificate renewals > > [error] DBusException: org.fedorahosted.certmonger.bad_arg: The > location > > "/etc/pki/pki-tomcat/alias" could not be accessed due to insufficient > > permissions. > > > > > > Don't know if you need the command for how I was installing ipa. But > here > > is the line from my anseible playbook. > > shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername > > }} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns > > --forwarder={{ dnsforwarder }} -U creates={{ slapd }} > > > > On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek > wrote: > > > > > On 11/19/2014 11:57 AM, Tamas Papp wrote: > > > > I am good in waiting;) > > > > > > > > Thanks for the prompt reply. > > > > > > Ok Tamas, I think we *finally* got somewhere. Can you please try the > > > mkosek/freeipa Copr repo now? > > > > > > I was able to install upstream "freeipa-server" 4.1.1 package on my > > > RHEL-7.0 > > > machine (should be the same for CentOS) and run ipa-server-install: > > > > > > # yum install freeipa-server --enablerepo=mkosek-freeipa > > > ... > > > Resolving Dependencies > > > --> Running transaction check > > > ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be > installed > > > ... > > > Transaction Summary > > > > > > > ======================================================================================================== > > > Install 1 Package (+338 Dependent packages) > > > Upgrade ( 11 Dependent packages) > > > > > > Total download size: 146 M > > > ... > > > > > > # rpm -q freeipa-server > > > freeipa-server-4.1.1-1.2.el7.centos.x86_64 > > > > > > # ipa-server-install --setup-dns > > > > > > # kinit admin > > > Password for admin at EXAMPLE.COM: > > > > > > Thanks, > > > Martin > > > > > > -- > > > 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 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Nov 19 19:45:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 20:45:28 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> Message-ID: <546CF358.7080608@redhat.com> Good news! To clarify on the selinux-policy side. By not maintaining it for the CentOS I meant that FreeIPA Copr should not maintain system policy for any system, not just SELinux. Ideally, it should have a SELinux policy module that would be compiled for SELinux only and that would only contain the additional policy required by IPA on top of 7.0. But this is not a priority for now & we do not have enough capacity for it ATM. But if anyone wishes to contribute that part, doors are open :-) Martin On 11/19/2014 05:56 PM, Bill Peck wrote: > > Hi Martin, > > Yes, setting selinux to permissive allowed me to install and configure IPA 4.1 > on CentOS 7. > > :-) > > On Wed, Nov 19, 2014 at 11:41 AM, Martin Kosek > wrote: > > It is highly probable the issue is caused by SELinux (check for AVCs in > /var/log/audit/audit.log). > > Can you try with SELinux permissive? We specifically did not build > selinux-policy as we do not think we should be the ones maintaining it for > CentOS. > > HTH, > Martin > > ----- Original Message ----- > > From: "Bill Peck" > > > To: "Martin Kosek" > > > Cc: "Tamas Papp" >, > freeipa-users at redhat.com > > Sent: Wednesday, November 19, 2014 5:34:10 PM > > Subject: Re: [Freeipa-users] freeipa-server from copr repo > > > > Hi Marin, > > > > I was able to install from the copr repo now as well. Thank you! > > > > However I wasn't able to finish the install: > > > > [23/27]: configure certmonger for renewals > > [24/27]: configure certificate renewals > > [error] DBusException: org.fedorahosted.certmonger.bad_arg: The location > > "/etc/pki/pki-tomcat/alias" could not be accessed due to insufficient > > permissions. > > > > > > Don't know if you need the command for how I was installing ipa. But here > > is the line from my anseible playbook. > > shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername > > }} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns > > --forwarder={{ dnsforwarder }} -U creates={{ slapd }} > > > > On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek > wrote: > > > > > On 11/19/2014 11:57 AM, Tamas Papp wrote: > > > > I am good in waiting;) > > > > > > > > Thanks for the prompt reply. > > > > > > Ok Tamas, I think we *finally* got somewhere. Can you please try the > > > mkosek/freeipa Copr repo now? > > > > > > I was able to install upstream "freeipa-server" 4.1.1 package on my > > > RHEL-7.0 > > > machine (should be the same for CentOS) and run ipa-server-install: > > > > > > # yum install freeipa-server --enablerepo=mkosek-freeipa > > > ... > > > Resolving Dependencies > > > --> Running transaction check > > > ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be > installed > > > ... > > > Transaction Summary > > > > > > > ======================================================================================================== > > > Install 1 Package (+338 Dependent packages) > > > Upgrade ( 11 Dependent packages) > > > > > > Total download size: 146 M > > > ... > > > > > > # rpm -q freeipa-server > > > freeipa-server-4.1.1-1.2.el7.centos.x86_64 > > > > > > # ipa-server-install --setup-dns > > > > > > # kinit admin > > > Password for admin at EXAMPLE.COM : > > > > > > Thanks, > > > Martin > > > > > > -- > > > 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 > > > > > > > From tompos at martos.bme.hu Wed Nov 19 20:23:52 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 19 Nov 2014 21:23:52 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> Message-ID: <546CFC58.5090001@martos.bme.hu> hi Martin, Much better:) Unfortunately not perfect yet. [...] Done configuring DNS key synchronization service (ipa-dnskeysyncd). Restarting ipa-dnskeysyncd Restarting named ipa : ERROR Named service failed to start (Command ''/bin/systemctl' 'restart' 'named-pkcs11.service'' returned non-zero exit status 1) named service failed to start Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files Restarting the web server Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command ''/bin/systemctl' 'restart' 'ipa.service'' returned non-zero exit status 1 This helped: chmod 777 /var/named/dyndb-ldap/ipa/ Probably chown or chgrp named would be just enough. Cheers, tamas On 11/19/2014 05:41 PM, Martin Kosek wrote: > It is highly probable the issue is caused by SELinux (check for AVCs in /var/log/audit/audit.log). > > Can you try with SELinux permissive? We specifically did not build selinux-policy as we do not think we should be the ones maintaining it for CentOS. > > HTH, > Martin > > ----- Original Message ----- >> From: "Bill Peck" >> To: "Martin Kosek" >> Cc: "Tamas Papp" , freeipa-users at redhat.com >> Sent: Wednesday, November 19, 2014 5:34:10 PM >> Subject: Re: [Freeipa-users] freeipa-server from copr repo >> >> Hi Marin, >> >> I was able to install from the copr repo now as well. Thank you! >> >> However I wasn't able to finish the install: >> >> [23/27]: configure certmonger for renewals >> [24/27]: configure certificate renewals >> [error] DBusException: org.fedorahosted.certmonger.bad_arg: The location >> "/etc/pki/pki-tomcat/alias" could not be accessed due to insufficient >> permissions. >> >> >> Don't know if you need the command for how I was installing ipa. But here >> is the line from my anseible playbook. >> shell: ipa-server-install -a {{ adminpassword }} --hostname={{ servername >> }} -r {{ realm }} -p {{ directorypassword }} -n {{ domain }} --setup-dns >> --forwarder={{ dnsforwarder }} -U creates={{ slapd }} >> >> On Wed, Nov 19, 2014 at 11:23 AM, Martin Kosek wrote: >> >>> On 11/19/2014 11:57 AM, Tamas Papp wrote: >>>> I am good in waiting;) >>>> >>>> Thanks for the prompt reply. >>> Ok Tamas, I think we *finally* got somewhere. Can you please try the >>> mkosek/freeipa Copr repo now? >>> >>> I was able to install upstream "freeipa-server" 4.1.1 package on my >>> RHEL-7.0 >>> machine (should be the same for CentOS) and run ipa-server-install: >>> >>> # yum install freeipa-server --enablerepo=mkosek-freeipa >>> ... >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package freeipa-server.x86_64 0:4.1.1-1.2.el7.centos will be installed >>> ... >>> Transaction Summary >>> >>> ======================================================================================================== >>> Install 1 Package (+338 Dependent packages) >>> Upgrade ( 11 Dependent packages) >>> >>> Total download size: 146 M >>> ... >>> >>> # rpm -q freeipa-server >>> freeipa-server-4.1.1-1.2.el7.centos.x86_64 >>> >>> # ipa-server-install --setup-dns >>> >>> # kinit admin >>> Password for admin at EXAMPLE.COM: >>> >>> Thanks, >>> Martin >>> >>> -- >>> 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 >>> From mkosek at redhat.com Wed Nov 19 20:29:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 21:29:32 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546CFC58.5090001@martos.bme.hu> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> Message-ID: <546CFDAC.8020608@redhat.com> On 11/19/2014 09:23 PM, Tamas Papp wrote: > hi Martin, > > Much better:) > Unfortunately not perfect yet. > > [...] > Done configuring DNS key synchronization service (ipa-dnskeysyncd). > Restarting ipa-dnskeysyncd > Restarting named > ipa : ERROR Named service failed to start (Command ''/bin/systemctl' > 'restart' 'named-pkcs11.service'' returned non-zero exit status 1) > named service failed to start > > Global DNS configuration in LDAP server is empty > You can use 'dnsconfig-mod' command to set global DNS options that > would override settings in local named.conf files > > Restarting the web server > Unexpected error - see /var/log/ipaserver-install.log for details: > CalledProcessError: Command ''/bin/systemctl' 'restart' 'ipa.service'' returned > non-zero exit status 1 > > > This helped: > > chmod 777 /var/named/dyndb-ldap/ipa/ > > Probably chown or chgrp named would be just enough. > > > Cheers, > tamas Ah, yes. This one is not a problem with the CentOS port, but rather existing problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all platforms, including Fedora 21 and CentOS. See upstream ticket: https://fedorahosted.org/freeipa/ticket/4716 Until this is fixed, correct workaround is to chown this directory by named:named and chmod rights to 0770. I will with the team when 4.1.2 is about to be released, if it is not soon, I can just add the patch to the 4.1.1 in Copr repo. Martin From tompos at martos.bme.hu Wed Nov 19 21:24:03 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 19 Nov 2014 22:24:03 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546CFDAC.8020608@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> Message-ID: <546D0A73.3080206@martos.bme.hu> On 11/19/2014 09:29 PM, Martin Kosek wrote: > > Ah, yes. This one is not a problem with the CentOS port, but rather > existing problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 > on all platforms, including Fedora 21 and CentOS. > > See upstream ticket: > https://fedorahosted.org/freeipa/ticket/4716 > > Until this is fixed, correct workaround is to chown this directory by > named:named and chmod rights to 0770. > > I will with the team when 4.1.2 is about to be released, if it is not > soon, I can just add the patch to the 4.1.1 in Copr repo. Thanks for all. Just a question. My understanding is that 4.x will not hit RH 7 ever. So for IPA 4.x we have to wait until RH8, am I correct? Thanks, tamas From mkosek at redhat.com Wed Nov 19 21:27:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 22:27:10 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546D0A73.3080206@martos.bme.hu> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> <546D0A73.3080206@martos.bme.hu> Message-ID: <546D0B2E.2070007@redhat.com> On 11/19/2014 10:24 PM, Tamas Papp wrote: > > On 11/19/2014 09:29 PM, Martin Kosek wrote: >> >> Ah, yes. This one is not a problem with the CentOS port, but rather existing >> problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all >> platforms, including Fedora 21 and CentOS. >> >> See upstream ticket: >> https://fedorahosted.org/freeipa/ticket/4716 >> >> Until this is fixed, correct workaround is to chown this directory by >> named:named and chmod rights to 0770. >> >> I will with the team when 4.1.2 is about to be released, if it is not soon, I >> can just add the patch to the 4.1.1 in Copr repo. > > Thanks for all. > > Just a question. My understanding is that 4.x will not hit RH 7 ever. > So for IPA 4.x we have to wait until RH8, am I correct? > > Thanks, > tamas Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) Martin From tompos at martos.bme.hu Wed Nov 19 21:28:43 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 19 Nov 2014 22:28:43 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546D0B2E.2070007@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> <546D0A73.3080206@martos.bme.hu> <546D0B2E.2070007@redhat.com> Message-ID: <546D0B8B.6070506@martos.bme.hu> On 11/19/2014 10:27 PM, Martin Kosek wrote: > > Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release > - so you can look forward to that :-) Very good! Then everything is good for testing:) t From emteeoh at gmail.com Thu Nov 20 02:55:51 2014 From: emteeoh at gmail.com (Richard Betel) Date: Wed, 19 Nov 2014 21:55:51 -0500 Subject: [Freeipa-users] buggered 389? Message-ID: I suddenly started getting errors when I try to use ipa-getkeytab: [root at ipa1 kerberize]# ipa-getkeytab -s jn01 -p hdfs/jn01 -k jn01.hdfs.keytab SASL Bind failed Can't contact LDAP server (-1) ! ldap seems to be answering on the non-SASL port (ei: ldapsearch -x -h localhost CN=richard works fine) but if I don't use the -x, I get: ldapsearch -h localhost CN=richard SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: I'm kinda at a loss for how to debug this. I'm not really finding any errors in the dirsrv logs, just a warning that my DB is bigger than the cache. I'd appreciate some ideas on where to look. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Thu Nov 20 03:41:27 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Thu, 20 Nov 2014 03:41:27 +0000 (UTC) Subject: [Freeipa-users] DNS forwarders Message-ID: <850912593.2932672.1416454887477.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> I have a quick question?Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually..? TIA -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Thu Nov 20 07:10:49 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Thu, 20 Nov 2014 07:10:49 +0000 (UTC) Subject: [Freeipa-users] DNS forwarders In-Reply-To: <850912593.2932672.1416454887477.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> References: <850912593.2932672.1416454887477.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> Message-ID: <1485278518.2977710.1416467449641.JavaMail.yahoo@jws106132.mail.bf1.yahoo.com> I've installed freeipa 4.1.1 --setup-dns --no-forwarders?so far the installation went well .. but I need to configure freeipa server as a forwarder right? so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. after the reboot I couldn't access the web browser.? Any idea on how can I fix this??? TIA On Wednesday, November 19, 2014 7:41 PM, Rolf Nufable wrote: I have a quick question?Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually..? TIA -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Thu Nov 20 07:18:02 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Thu, 20 Nov 2014 07:18:02 +0000 (UTC) Subject: [Freeipa-users] Freeipa Forwarders Message-ID: <740323710.3185413.1416467882151.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> I have a quick question?Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually..? **********************UPDATE ************************************************ I've installed freeipa 4.1.1 --setup-dns --no-forwarders?so far the installation went well .. but I need to configure freeipa server as a forwarder right? so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. after the reboot I couldn't access the web browser.? Any idea on how can I fix this??? TIA -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Nov 20 08:34:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Nov 2014 09:34:43 +0100 Subject: [Freeipa-users] DNS forwarders In-Reply-To: <1485278518.2977710.1416467449641.JavaMail.yahoo@jws106132.mail.bf1.yahoo.com> References: <850912593.2932672.1416454887477.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> <1485278518.2977710.1416467449641.JavaMail.yahoo@jws106132.mail.bf1.yahoo.com> Message-ID: <546DA7A3.1060908@redhat.com> On 11/20/2014 08:10 AM, Rolf Nufable wrote: > I've installed freeipa 4.1.1 --setup-dns --no-forwarders so far the installation went well .. but I need to configure freeipa server as a forwarder right? > so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. > after the reboot I couldn't access the web browser. > Any idea on how can I fix this?? > TIA > > On Wednesday, November 19, 2014 7:41 PM, Rolf Nufable wrote: > > > I have a quick question Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? > I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually.. > TIA Forwarders just allows you to configure BIND to forward all requests for zones it does not manage to specified name server. Normally, this is not required if DNS is set correctly and BIND can simply get results by querying from top "." to the required zone (e.g. "example.com."). But in internal networks or special deployments, you need to set up the forwarders, yes. Just make sure they point to some recursive DNS server. More on this topic in this book for example: http://www.zytrax.com/books/dns/ch4/ About your problem - it is probably DNS. Check where your resolv.conf is pointing, check if DNS (named service) is running. Check that IPA is really running (ipactl status) and you should find where the problem is. Martin From tlau at tetrioncapital.com Thu Nov 20 09:04:02 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Thu, 20 Nov 2014 17:04:02 +0800 Subject: [Freeipa-users] Laptop user Message-ID: Does anyone know what's the behavior look like if a mobile user (laptop) being disconnected from Kerberos for too long even cache is enabled by default in our environment? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Nov 20 09:07:30 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 20 Nov 2014 10:07:30 +0100 Subject: [Freeipa-users] buggered 389? In-Reply-To: References: Message-ID: <20141120090730.GE14090@localhost.localdomain> On Wed, Nov 19, 2014 at 09:55:51PM -0500, Richard Betel wrote: > I suddenly started getting errors when I try to use ipa-getkeytab: > > [root at ipa1 kerberize]# ipa-getkeytab -s jn01 -p hdfs/jn01 -k > jn01.hdfs.keytab > SASL Bind failed Can't contact LDAP server (-1) ! Please try to use the fully qualified name of the server. > > ldap seems to be answering on the non-SASL port (ei: ldapsearch -x -h > localhost CN=richard works fine) but if I don't use the -x, I get: > ldapsearch -h localhost CN=richard > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: As Alexander educated me, this is expected because SASL/EXTERNAL is only used for the ldapi connection scheme. Please try to use the fully qualified server name and '-Y GSSAPI' with ldapsearch. HTH bye, Sumit > > > I'm kinda at a loss for how to debug this. I'm not really finding any > errors in the dirsrv logs, just a warning that my DB is bigger than the > cache. I'd appreciate some ideas on where to look. > -- > 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 From jhrozek at redhat.com Thu Nov 20 09:10:13 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 20 Nov 2014 10:10:13 +0100 Subject: [Freeipa-users] Laptop user In-Reply-To: References: Message-ID: <20141120091013.GI12319@hendrix.brq.redhat.com> On Thu, Nov 20, 2014 at 05:04:02PM +0800, Thomas Lau wrote: > Does anyone know what's the behavior look like if a mobile user (laptop) > being disconnected from Kerberos for too long even cache is enabled by > default in our environment? SSSD caches the user data and if cache_credentials is enabled, then also a salted password hash to enable offline logins. Your TGT will eventually expire, but that hardly matters since you're offline. When you reconnect to the network, you can either run kinit manually, or for better user experience enable krb5_store_password_if_offline to keep your password in the kernel keyring and let sssd kinit on your behalf when it detects you've gone online again. From tlau at tetrioncapital.com Thu Nov 20 09:19:57 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Thu, 20 Nov 2014 17:19:57 +0800 Subject: [Freeipa-users] Laptop user In-Reply-To: <20141120091013.GI12319@hendrix.brq.redhat.com> References: <20141120091013.GI12319@hendrix.brq.redhat.com> Message-ID: What will happen if laptop haven't turn on for a long time and ticket expired with cache and store password enabled? Does user unable to login after expired? On Thu, Nov 20, 2014 at 5:10 PM, Jakub Hrozek wrote: > On Thu, Nov 20, 2014 at 05:04:02PM +0800, Thomas Lau wrote: > > Does anyone know what's the behavior look like if a mobile user (laptop) > > being disconnected from Kerberos for too long even cache is enabled by > > default in our environment? > > SSSD caches the user data and if cache_credentials is enabled, then also > a salted password hash to enable offline logins. > > Your TGT will eventually expire, but that hardly matters since you're > offline. When you reconnect to the network, you can either run kinit > manually, or for better user experience enable > krb5_store_password_if_offline > to keep your password in the kernel keyring and let sssd kinit on your > behalf when it detects you've gone online again. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Nov 20 09:35:30 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 20 Nov 2014 10:35:30 +0100 Subject: [Freeipa-users] Laptop user In-Reply-To: References: <20141120091013.GI12319@hendrix.brq.redhat.com> Message-ID: <20141120093530.GK12319@hendrix.brq.redhat.com> On Thu, Nov 20, 2014 at 05:19:57PM +0800, Thomas Lau wrote: > What will happen if laptop haven't turn on for a long time and ticket > expired with cache and store password enabled? Does user unable to login > after expired? SSSD doesn't use the ticket to authenticate in offline case, so sssd doesn't really care the ticket expired. Rather, when cache_credentials is enabled, we store a hash of the user's password in the cache and if offline, compare what the user entered with the stored hash. By default, the cache password hash never expires, unless you configure sssd to do so with offline_credentials_expiration > > On Thu, Nov 20, 2014 at 5:10 PM, Jakub Hrozek wrote: > > > On Thu, Nov 20, 2014 at 05:04:02PM +0800, Thomas Lau wrote: > > > Does anyone know what's the behavior look like if a mobile user (laptop) > > > being disconnected from Kerberos for too long even cache is enabled by > > > default in our environment? > > > > SSSD caches the user data and if cache_credentials is enabled, then also > > a salted password hash to enable offline logins. > > > > Your TGT will eventually expire, but that hardly matters since you're > > offline. When you reconnect to the network, you can either run kinit > > manually, or for better user experience enable > > krb5_store_password_if_offline > > to keep your password in the kernel keyring and let sssd kinit on your > > behalf when it detects you've gone online again. > > > > -- > > 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 > > From tlau at tetrioncapital.com Thu Nov 20 09:36:14 2014 From: tlau at tetrioncapital.com (Thomas Lau) Date: Thu, 20 Nov 2014 17:36:14 +0800 Subject: [Freeipa-users] Laptop user In-Reply-To: <20141120093530.GK12319@hendrix.brq.redhat.com> References: <20141120091013.GI12319@hendrix.brq.redhat.com> <20141120093530.GK12319@hendrix.brq.redhat.com> Message-ID: Thanks, that solve my concern! On Thu, Nov 20, 2014 at 5:35 PM, Jakub Hrozek wrote: > On Thu, Nov 20, 2014 at 05:19:57PM +0800, Thomas Lau wrote: > > What will happen if laptop haven't turn on for a long time and ticket > > expired with cache and store password enabled? Does user unable to login > > after expired? > > SSSD doesn't use the ticket to authenticate in offline case, so sssd > doesn't really care the ticket expired. > > Rather, when cache_credentials is enabled, we store a hash of the user's > password in the cache and if offline, compare what the user entered > with the stored hash. > > By default, the cache password hash never expires, unless you configure > sssd to do so with offline_credentials_expiration > > > > > > On Thu, Nov 20, 2014 at 5:10 PM, Jakub Hrozek > wrote: > > > > > On Thu, Nov 20, 2014 at 05:04:02PM +0800, Thomas Lau wrote: > > > > Does anyone know what's the behavior look like if a mobile user > (laptop) > > > > being disconnected from Kerberos for too long even cache is enabled > by > > > > default in our environment? > > > > > > SSSD caches the user data and if cache_credentials is enabled, then > also > > > a salted password hash to enable offline logins. > > > > > > Your TGT will eventually expire, but that hardly matters since you're > > > offline. When you reconnect to the network, you can either run kinit > > > manually, or for better user experience enable > > > krb5_store_password_if_offline > > > to keep your password in the kernel keyring and let sssd kinit on your > > > behalf when it detects you've gone online again. > > > > > > -- > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu Nov 20 10:00:25 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Nov 2014 11:00:25 +0100 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <546C599B.9090101@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> Message-ID: <546DBBB9.5030404@redhat.com> Hello Will, Daniel, Server1 successfully replicated to Server2, but Server2 fails to replicated to Server1. The replication Server2->Server1 is done with kerberos authentication. Server1 receives the replication session, successfully identify the replication manager, start to receives replication extop but suddenly closes the connection. [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from xxx to yyy [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=xxx" [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O function error. The reason of this closure is logged in server1 error log. sasl_decode fails to decode a received PDU. [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet for connection 2980 I do not know why it fails but I wonder if the received PDU is not larger than the maximum configured value. The attribute nsslapd-maxsasliosize is set to 2Mb by default. Would it be possible to increase its value (5Mb) to see if it has an impact Thanks thierry On 11/19/2014 09:49 AM, thierry bordaz wrote: > On 11/18/2014 07:44 PM, Will Sheldon wrote: >> >> No, not resolved yet I did test with GSSAPI (-Y) and like you it >> worked. :( > > Hello, > > Would it be possible to get server1/server2 logs (error/access) and > config (dse.ldif) ?. Turning on replication logs would help ( > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting). > > In the sample of the log, there is a failure while ending a > replication session. No replication error before ? > It is like suddenly server1 was no longer able to reach server2 (dns > or network issue ?). > > thanks > thierry >> >> >> Will Sheldon >> >> On November 18, 2014 at 8:37:10 AM, dbischof at hrz.uni-kassel.de >> (dbischof at hrz.uni-kassel.de ) wrote: >> >>> Hi, >>> >>> On Fri, 7 Nov 2014, Dmitri Pal wrote: >>> >>> > On 11/07/2014 01:24 AM, Will Sheldon wrote: >>> >> On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com >>> >> ) wrote: >>> >>> On 11/07/2014 12:18 AM, Will Sheldon wrote: >>> >>>> >>> >>>> On the whole we are loving FreeIPA, Many thanks and much >>> respect to >>> >>>> all involved, we've had a great 12-18 months hassle free use >>> out of >>> >>>> it - it is a fantastically stable trouble free solution... >>> however now >>> >>>> we've run into a small issue we (as mere mortals) are finding >>> it hard >>> >>>> to resolve :-/ >>> >>>> >>> >>>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything >>> >>>> seems to go well, but one server is behaving oddly. It's likely >>> not >>> >>>> an IPA issue, it also reset it's hostname somehow after the >>> upgrade >>> >>>> (it's an image in an openstack environment) >>> >>>> >>> >>>> If anyone has any pointers as to how to debug I'd be hugely >>> >>>> appreciative :) >>> >>>> >>> >>>> Two servers, server1.domain.com and server2.domain.com >>> >>>> >>> >>>> Server1 can't push data to server2, there are updates and new >>> records >>> >>>> on server1 that do not exist on server2. >>> >>>> >>> >>>> >>> >>>> from the logs on server1: >>> >>>> >>> >>>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin - >>> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable >>> to send >>> >>>> endReplication extended operation (Can't contact LDAP server) >>> >>>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin - >>> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Replication >>> bind with >>> >>>> GSSAPI auth resumed >>> >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to >>> >>>> replicate schema: rc=2 >>> >>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin - >>> >>>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed >>> to replay >>> >>>> change (uniqueid (null), CSN (null)): Can't contact LDAP >>> server(-1). Will >>> >>>> retry later. >>> >>> >>> >>> Try to see >>> >>> a) Server 1 properly resolves server 2 >>> >>> b) You can connect from server 1 to server 2 using ldapsearch >>> >>> c) your firewall has proper ports open >>> >>> d) dirserver on server 2 is actually running >>> >> >>> >> All seems working: >>> >> >>> >> [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s >>> base -b '' >>> >> namingContexts >>> > >>> > Can you try kinit admin and then use kerberos GSSAPI to connect, >>> i.e. -Y >>> > switch? >>> >>> is this resolved? I observe it on my systems, too. Exact same symptoms. >>> ldapsearch with "-Y GSSAPI" works. >>> >>> > Did you find anything in the server2 logs? >>> >>> On my "server2", I see "sasl_io_recv failed to decode packet for >>> connection #". >>> >>> Could there be something wrong with default buffer sizes as >>> described in >>> https://bugzilla.redhat.com/show_bug.cgi?id=953653 >>> >>> I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my >>> database is rather small: ~30 users, <10 hosts and services. >>> >>> >> # extended LDIF >>> >> # >>> >> # LDAPv3 >>> >> # base <> with scope baseObject >>> >> # filter: (objectclass=*) >>> >> # requesting: namingContexts >>> >> # >>> >> >>> >> # >>> >> dn: >>> >> namingContexts: dc=domain,dc=com >>> >> >>> >> # search result >>> >> search: 2 >>> >> result: 0 Success >>> >> >>> >> # numResponses: 2 >>> >> # numEntries: 1 >>> >> [root at server1 ~]# >>> >> >>> >> And: >>> >> >>> >> [root at server2 ~]# /etc/init.d/dirsrv status >>> >> dirsrv DOMAIN-COM (pid 1009) is running... >>> >> dirsrv PKI-IPA (pid 1083) is running... >>> >> [root at server2 ~]# >>> >> >>> >>> >>> >>> Check logs on server 2 to see whether it actually sees an >>> attempt to >>> >>> connect, I suspect not, so it is most likely a DNS/FW issue or >>> dir server >>> >>> is not running on 2. >>> >>>> >>> >>>> >>> >>>> and the servers: >>> >>>> >>> >>>> [root at server1 ~]# ipa-replica-manage list -v `hostname` >>> >>>> Directory Manager password: >>> >>>> >>> >>>> server2.domain.com: replica >>> >>>> last init status: None >>> >>>> last init ended: None >>> >>>> last update status: 0 Replica acquired successfully: >>> Incremental update >>> >>>> started >>> >>>> last update ended: 2014-11-07 01:35:58+00:00 >>> >>>> [root at server1 ~]# >>> >>>> >>> >>>> >>> >>>> >>> >>>> [root at server2 ~]# ipa-replica-manage list -v `hostname` >>> >>>> Directory Manager password: >>> >>>> >>> >>>> server1.domain.com: replica >>> >>>> last init status: None >>> >>>> last init ended: None >>> >>>> last update status: 0 Replica acquired successfully: >>> Incremental update >>> >>>> succeeded >>> >>>> last update ended: 2014-11-07 01:35:43+00:00 >>> >>>> [root at server2 ~]# >>> >>> >>> Mit freundlichen Gruessen/With best regards, >>> >>> --Daniel. >>> >>> -- >>> 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 >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmj at ast.cam.ac.uk Thu Nov 20 10:54:22 2014 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 20 Nov 2014 10:54:22 +0000 Subject: [Freeipa-users] Problem migrating passwords fro NIS to IdM In-Reply-To: <546CB07D.1040106@redhat.com> References: <546B887B.5060004@ast.cam.ac.uk> <546BC602.5020900@redhat.com> <546BC6FF.90106@ast.cam.ac.uk> <546BCEFF.9080806@redhat.com> <546C55C8.1020106@ast.cam.ac.uk> <546C6F6A.3050308@ast.cam.ac.uk> <546CAEDE.6050702@redhat.com> <546CB07D.1040106@redhat.com> Message-ID: <546DC85E.4030303@ast.cam.ac.uk> On 19/11/14 15:00, Rob Crittenden wrote: > Rob Crittenden wrote: >> Roderick Johnstone wrote: >>> On 19/11/2014 08:33, Roderick Johnstone wrote: >>>> On 18/11/2014 22:58, Rob Crittenden wrote: >>>>> Roderick Johnstone wrote: >>>>>> On 18/11/2014 22:19, Dmitri Pal wrote: >>>>>>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still >>>>>>>> keeping the original passwords. >>>>>>>> >>>>>>>> I followed the instructions at: >>>>>>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The passwords are in SHA-512 format and I have been testing the >>>>>>>> migration with commands like this (generated via a script from my nis >>>>>>>> passwd file) on my IdM server: >>>>>>>> >>>>>>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx >>>>>>>> --uid=xxxx >>>>>>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash >>>>>>>> --setattr userpassword='{SHA-512}xxxxxxx' >>>>>>>> >>>>>>>> where the xxxxxxx is the hashed password from the NIS password file >>>>>>>> with the leading $6$ stripped off. >>>>>>>> >>>>>>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm >>>>>>>> left with: >>>>>>>> passwd: files sss >>>>>>>> >>>>>>>> and the account that I migrated cannot log in. >>>>>>>> >>>>>>>> From the sssd log file (below) it looks like its trying to migrate >>>>>>>> the >>>>>>>> password but failing with an LDAP authentication failure. >>>>>>>> >>>>>>>> I'd appreciate any pointers to how to find out whats going wrong >>>>>>>> here. >>>>>>>> >>>>>>>> Accounts which I created manually in the web gui are working ok. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Roderick Johnstone >>>>>>>> >>>>>>>> Part of sssd log file >>>>>>>> ===================== >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' >>>>>>>> as 'working' >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server >>>>>>>> 'xxx.xxx.xxx.xxx' as 'working' >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos >>>>>>>> password >>>>>>>> is missing, starting password migration. >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send] >>>>>>>> (0x0100): Executing simple bind as: >>>>>>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done] >>>>>>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>>>>>>> migration not possible. >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, ) >>>>>>>> [Success] >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx] >>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] >>>>>>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx] >>>>>>>> >>>>>>> >>>>>>> Did you enable migration mode on the IPA server? >>>>>>> >>>>>> >>>>>> Yes, I ran: >>>>>> ipa config-mod --enable-migration=true >>>>>> on the IPA server. >>>>>> >>>>>> Roderick >>>>>> >>>>> >>>>> The has name probably needs to match something in cn=Password Storage >>>>> Schemes,cn=plugins,cn=config. >>>>> >>>>> I'd try either {SHA512} or {SSHA512} and see if one of those works >>>>> better. >>>>> >>>>> rob >>>>> >>>> >>>> Rob >>>> >>>> I had wondered about the specification of the password hash type. >>>> >>>> I chose SHA-512 as it seemed to be suggested in the >>>> passwordStorageScheme attribute described in Table 14.1 of the Redhat >>>> Directory Server Admin Guide, >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html. >>>> >>>> But now I come to re-read that doc it suggests perhaps that SHA covers >>>> all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as >>>> the userpassword specification. >>>> >>>> I have also seen the userpassword attribute referred to in other places >>>> as userPassword and wondered whether the attribute name is case >>>> sensitive. Do you know? >>>> >>>> Thanks for your input. >>>> >>>> Roderick >>>> >>> >>> Rob >>> >>> I just tried with --setattr userpassword='{SHA}xxxxxxx' but I get the >>> same result: >>> [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no >>> errmsg set >>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password >>> migration not possible. >>> >>> I'm wondering if its something to do with the quoting. The hashed >>> password contains $ and there are the {} around the SHA so I'm using >>> strong single quotes to prevent anything following the $ being >>> interpreted as a variable, I hope. Maybe this is a ref herring. >>> >> >> I think your quoting is correct. >> >> I've only used this method with crypt passwords. I guess theoretically >> it should work with other crypt(3) schemes but I've never tried. There >> could be some 389-ds-specific gotchas. >> >> Crypt defines the storage as $id$salt$encrypted so perhaps strip out the >> $id$ part since that is being defined by {SHA}, but I'm really only >> guessing. The 389-ds guys may know. >> >> LDAP attributes are not case sensitive. > > Ok, this question was bugging me so I took a second to look into it. > > The trick is to use CRYPT and not be too clever about knowing the scheme > the password is stored in. > > This worked for me: > > # grep myuser /etc/shadow > $ ipa user-add --first=test --last=user --setattr > userpassword='{CRYPT}$6$blahblah$moregibberish' testuser > $ ldapsearch -x -D 'uid=testuser,cn=users,cn=accounts,dc=example,dc=com' -W > Enter LDAP Password: > > > rob > Rob Fantastic! This works for me too. Thank you so much. Roderick From dbischof at hrz.uni-kassel.de Thu Nov 20 11:03:48 2014 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Thu, 20 Nov 2014 12:03:48 +0100 (CET) Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <546DBBB9.5030404@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> Message-ID: Hi, On Thu, 20 Nov 2014, thierry bordaz wrote: > Server1 successfully replicated to Server2, but Server2 fails to > replicated to Server1. > > The replication Server2->Server1 is done with kerberos authentication. > Server1 receives the replication session, successfully identify the > replication manager, start to receives replication extop but suddenly > closes the connection. > > > [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from > xxx to yyy > [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 dn="krbprincipalname=xxx" > [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 > nentries=1 etime=0 > [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT > oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" > [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 > nentries=0 etime=0 > [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" > scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" > [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 > nentries=1 etime=0 > [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O > function error. > > The reason of this closure is logged in server1 error log. sasl_decode fails > to decode a received PDU. > > [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet > for connection 2980 > > I do not know why it fails but I wonder if the received PDU is not larger > than the maximum configured value. The attribute nsslapd-maxsasliosize is set > to 2Mb by default. Would it be possible to increase its value (5Mb) to see if > it has an impact > > [...] I set nsslapd-maxsasliosize to 6164480 on both machines, but the problem remains. Mit freundlichen Gruessen/With best regards, --Daniel. From jcholast at redhat.com Thu Nov 20 12:06:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 13:06:44 +0100 Subject: [Freeipa-users] Antwort: Re: Multiple Domains and SSH In-Reply-To: References: <546BC43C.5070305@redhat.com><126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> <546C3E02.9020804@redhat.com> Message-ID: <546DD954.8040801@redhat.com> Hi, Dne 19.11.2014 v 09:45 Christoph Kaminski napsal(a): > this is an example of a host here and the ways how can I reach it via ssh: > (they are all in dns forward and reverse resolving) (note I redacted the hostnames and IP addresses in the output below) > > host host.mgmt > host.mgmt has address 192.168.1.1 > host 192.168.1.1 > 1.1.168.192.in-addr.arpa domain name pointer host.mgmt. > host host.mydom.int > host.mydom.int has address 192.168.2.1 > host 192.168.2.1 > 1.2.168.192.in-addr.arpa domain name pointer host.mydom.int. > host host.mydom.net > host.mydom.net has address 192.168.3.1 > host 192.168.3.1 > 1.3.168.192.in-addr.arpa domain name pointer host.mydom.net. So it's a host with multiple IP addresses? You have 2 options then: 1. Add a host entry with the SSH public key to IPA for each of the hostnames then, as Dmitri suggested. 2. Manually add the additional hostnames to the fqdn attribute of the host entry using ldapmodify. > > MfG > Christoph Kaminski > > > > > Von: Jan Cholasta > An: Jakub Hrozek , dpal at redhat.com > Kopie: freeipa-users at redhat.com > Datum: 19.11.2014 07:53 > Betreff: Re: [Freeipa-users] Multiple Domains and SSH > Gesendet von: freeipa-users-bounces at redhat.com > ------------------------------------------------------------------------ > > > > Hi, > > Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): > > > >> On 18 Nov 2014, at 23:12, Dmitri Pal wrote: > >> > >> On 11/18/2014 01:07 AM, Christoph Kaminski wrote: > >>> Hi > >>> > >>> I can reach each host here via ssh on multiple domains: > >>> > >>> host.mydom.int > >>> host mydom.net > >>> host.mgmt > >>> > >>> sss_ssh_knownhostproxy does work only on the domain which I have > use to register to ipa (mgmt), on the other domains I get ever "The > authenticity of host 'host.mydom.int ()' > can't be established."... why? > > Because it does not know that the hostnames refer to the same host. > > Do you have a reverse DNS record set up for the host? Does it point to > the same hostname that you used to register the host in IPA? > > >>> > >> > >> > >> And other hosts in those domains are not registered? > >> May be you should try to add a host entry and SSH digest to IPA even > if they are not enrolled? > > This would work too. > > >> > > > > Maybe Honza would have some tips for debugging... > > See pages 13-16 of > . > > Honza > > -- > Jan Cholasta > > -- > 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 > > > > www.biotronik.com > ------------------------------------------------------------------------ > *BIOTRONIK - excellence for life* > Established with the development of the first German pacemaker in 1963, > BIOTRONIK has upheld the highest quality standards in the fields of > cardiac rhythm management and vascular intervention in more than 100 > countries worldwide. We?ve developed advanced technologies and products > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > offers the broadest portfolio of cardiac devices with ProMRI?, an > advanced technology that gives patients access to magnetic resonance > (MR) scanning. > ------------------------------------------------------------------------ > BIOTRONIK SE & Co. KG > Woermannkehre 1, 12359 Berlin, Germany > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > Vertreten durch ihre Komplement?rin: > BIOTRONIK MT SE > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > ------------------------------------------------------------------------ > This e-mail and the information it contains including attachments are > confidential and meant only for use by the intended recipient(s); > disclosure or copying is strictly prohibited. If you are not addressed, > but in the possession of this e-mail, please notify the sender > immediately and delete the document. Honza -- Jan Cholasta From roman at naumenko.ca Thu Nov 20 13:15:01 2014 From: roman at naumenko.ca (Roman Naumenko) Date: Thu, 20 Nov 2014 08:15:01 -0500 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <5462191B.4080601@redhat.com> References: <5461F1AF.2000708@naumenko.ca> <20141111115209.GD19156@redhat.com> <5462068C.7020105@naumenko.ca> <20141111130831.GF19156@redhat.com> <5462191B.4080601@redhat.com> Message-ID: <546DE955.7030908@naumenko.ca> Rob Crittenden wrote on 11-11-14 9:11: > Alexander Bokovoy wrote: >> On Tue, 11 Nov 2014, Roman Naumenko wrote: >>> Alexander Bokovoy wrote on 11-11-14 6:52: >>>> On Tue, 11 Nov 2014, Roman Naumenko wrote: >>>>> I'd like to adjust process settings on freeipa server to fit it >>>>> better into virtual instance. >>>>> Is it possible to change settings of java, ns-slapd and apache >>>>> processes somewhere in config files and what those files are? >>>> http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service >>>> ----------------------- >>>> # For example, to pass additional options (for instance, -D >>>> definitions) to the >>>> # httpd binary at startup, you need to create a file named >>>> # "/etc/systemd/system/httpd.service" containing: >>>> # .include /lib/systemd/system/httpd.service >>>> # [Service] >>>> # Environment=OPTIONS=-DMY_DEFINE >>> Isn't it for startup options only? >> You've asked about settings for the processes, that's how it is done in >> systemd environment. Check systemd.resource-control(5) and >> systemd.exec(5) for details of what can be changed. >> >>> I need to set some of these, they are usually in httpd.conf >>> >>> >>> StartServers 12 >>> MinSpareServers 12 >>> MaxSpareServers 12 >>> MaxClients 12 >>> MaxRequestsPerChild 300 >>> >> This is Apache-specific config and as such should go into >> /etc/httpd/conf.d/, any file with .conf suffix there is automatically >> included by httpd during startup thanks to the following in >> /etc/httpd/conf/httpd.conf: >> >> # Load config files in the "/etc/httpd/conf.d" directory, if any. >> IncludeOptional conf.d/*.conf >> > It depends on the version of your distro. > > In recent Fedora a lot of configuration has been split out into separate > files. This particular configuration can be found in > /etc/httpd/conf.d/prefork.conf. > > For older releases, on RHEL-6 for example, it is still defined in > /etc/httpd/conf/httpd.conf. > > As for 389-ds, there is no magic-bullet tuning. It is very > environment-specific and heavily based on the size of your data. This > should help, https://github.com/richm/scripts/wiki/dbmon.sh > > rob Thank Rob, but I still can't find anything even close. Btw, any chance developers replace this outdated apache garbage with normal nginx configuration? This is ridiculous that simplest config options are so buried its literally impossible to find. There is no prefork.conf on Centros 7. cat /etc/redhat-release CentOS Linux release 7.0.1406 (Core) So anybody even changed apache settings for IPA server? --Roman From tbordaz at redhat.com Thu Nov 20 14:49:27 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Nov 2014 15:49:27 +0100 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> Message-ID: <546DFF77.7090104@redhat.com> On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: > Hi, > > On Thu, 20 Nov 2014, thierry bordaz wrote: > >> Server1 successfully replicated to Server2, but Server2 fails to >> replicated to Server1. >> >> The replication Server2->Server1 is done with kerberos >> authentication. Server1 receives the replication session, >> successfully identify the replication manager, start to receives >> replication extop but suddenly closes the connection. >> >> >> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from >> xxx to yyy >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="krbprincipalname=xxx" >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >> nentries=0 etime=0 >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >> function error. >> >> The reason of this closure is logged in server1 error log. >> sasl_decode fails to decode a received PDU. >> >> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet >> for connection 2980 >> >> I do not know why it fails but I wonder if the received PDU is not >> larger than the maximum configured value. The attribute >> nsslapd-maxsasliosize is set to 2Mb by default. Would it be possible >> to increase its value (5Mb) to see if it has an impact >> >> [...] > > I set nsslapd-maxsasliosize to 6164480 on both machines, but the > problem remains. > > > Mit freundlichen Gruessen/With best regards, > > --Daniel. Hello Daniel, The sasl-decode fails but the exact returned value is not logged. With standard version we may need to attach a debugger and then set a conditional breakpoint in sasl-decode just after conn->oparams.decode that will fire if result !=0. Now this can change the dynamic and possibly prevent the problem to occur again. The other option is to use an instrumented version to log this value. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From emteeoh at gmail.com Thu Nov 20 15:30:51 2014 From: emteeoh at gmail.com (Richard Betel) Date: Thu, 20 Nov 2014 10:30:51 -0500 Subject: [Freeipa-users] buggered 389? In-Reply-To: <20141120090730.GE14090@localhost.localdomain> References: <20141120090730.GE14090@localhost.localdomain> Message-ID: -Y GSSAPI fixed the ldap query. Thanks. I figured out the problem with the ipa-getkeytab. In short, it was PEBKAC. Thanks for the help. On Thu, Nov 20, 2014 at 4:07 AM, Sumit Bose wrote: > On Wed, Nov 19, 2014 at 09:55:51PM -0500, Richard Betel wrote: > > I suddenly started getting errors when I try to use ipa-getkeytab: > > > > [root at ipa1 kerberize]# ipa-getkeytab -s jn01 -p hdfs/jn01 -k > > jn01.hdfs.keytab > > SASL Bind failed Can't contact LDAP server (-1) ! > > Please try to use the fully qualified name of the server. > > > > > ldap seems to be answering on the non-SASL port (ei: ldapsearch -x -h > > localhost CN=richard works fine) but if I don't use the -x, I get: > > ldapsearch -h localhost CN=richard > > SASL/EXTERNAL authentication started > > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > > additional info: SASL(-4): no mechanism available: > > As Alexander educated me, this is expected because SASL/EXTERNAL is only > used for the ldapi connection scheme. Please try to use the fully > qualified server name and '-Y GSSAPI' with ldapsearch. > > HTH > > bye, > Sumit > > > > > > > I'm kinda at a loss for how to debug this. I'm not really finding any > > errors in the dirsrv logs, just a warning that my DB is bigger than the > > cache. I'd appreciate some ideas on where to look. > > > -- > > 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 > > -- > 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 > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 20 15:43:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Nov 2014 10:43:56 -0500 Subject: [Freeipa-users] Adjust settings for processes In-Reply-To: <546DE955.7030908@naumenko.ca> References: <5461F1AF.2000708@naumenko.ca> <20141111115209.GD19156@redhat.com> <5462068C.7020105@naumenko.ca> <20141111130831.GF19156@redhat.com> <5462191B.4080601@redhat.com> <546DE955.7030908@naumenko.ca> Message-ID: <546E0C3C.1060608@redhat.com> Roman Naumenko wrote: > Rob Crittenden wrote on 11-11-14 9:11: >> Alexander Bokovoy wrote: >>> On Tue, 11 Nov 2014, Roman Naumenko wrote: >>>> Alexander Bokovoy wrote on 11-11-14 6:52: >>>>> On Tue, 11 Nov 2014, Roman Naumenko wrote: >>>>>> I'd like to adjust process settings on freeipa server to fit it >>>>>> better into virtual instance. >>>>>> Is it possible to change settings of java, ns-slapd and apache >>>>>> processes somewhere in config files and what those files are? >>>>> http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service >>>>> ----------------------- >>>>> # For example, to pass additional options (for instance, -D >>>>> definitions) to the >>>>> # httpd binary at startup, you need to create a file named >>>>> # "/etc/systemd/system/httpd.service" containing: >>>>> # .include /lib/systemd/system/httpd.service >>>>> # [Service] >>>>> # Environment=OPTIONS=-DMY_DEFINE >>>> Isn't it for startup options only? >>> You've asked about settings for the processes, that's how it is done in >>> systemd environment. Check systemd.resource-control(5) and >>> systemd.exec(5) for details of what can be changed. >>> >>>> I need to set some of these, they are usually in httpd.conf >>>> >>>> >>>> StartServers 12 >>>> MinSpareServers 12 >>>> MaxSpareServers 12 >>>> MaxClients 12 >>>> MaxRequestsPerChild 300 >>>> >>> This is Apache-specific config and as such should go into >>> /etc/httpd/conf.d/, any file with .conf suffix there is automatically >>> included by httpd during startup thanks to the following in >>> /etc/httpd/conf/httpd.conf: >>> >>> # Load config files in the "/etc/httpd/conf.d" directory, if any. >>> IncludeOptional conf.d/*.conf >>> >> It depends on the version of your distro. >> >> In recent Fedora a lot of configuration has been split out into separate >> files. This particular configuration can be found in >> /etc/httpd/conf.d/prefork.conf. >> >> For older releases, on RHEL-6 for example, it is still defined in >> /etc/httpd/conf/httpd.conf. >> >> As for 389-ds, there is no magic-bullet tuning. It is very >> environment-specific and heavily based on the size of your data. This >> should help, https://github.com/richm/scripts/wiki/dbmon.sh >> >> rob > Thank Rob, but I still can't find anything even close. > > Btw, any chance developers replace this outdated apache garbage with > normal nginx configuration? > This is ridiculous that simplest config options are so buried its > literally impossible to find. > > There is no prefork.conf on Centros 7. > cat /etc/redhat-release > CentOS Linux release 7.0.1406 (Core) > > So anybody even changed apache settings for IPA server? You weren't exactly clear on what distribution you were on before now. It would appear that RHEL 7 (and clones, presumably) rely on the Apache defaults for this. You can always override with your own configuration file as necessary. You'd have to bring this up with the Apache package maintainers and/or upstream as to why default values were removed from the config. rob From william.muriithi at gmail.com Fri Nov 21 00:38:34 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 20 Nov 2014 19:38:34 -0500 Subject: [Freeipa-users] Mixing local FreeIPA users with active directory users Message-ID: <20141121003834.6037651.22833.8974@gmail.com> An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 21 00:42:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Nov 2014 19:42:30 -0500 Subject: [Freeipa-users] Mixing local FreeIPA users with active directory users In-Reply-To: <20141121003834.6037651.22833.8974@gmail.com> References: <20141121003834.6037651.22833.8974@gmail.com> Message-ID: <546E8A76.6080800@redhat.com> On 11/20/2014 07:38 PM, William Muriithi wrote: > ?Hi guys, > > I am wondering how one would go about allowing both ad users and > FreeIPA user to work in harmony. > > I recently was able to get FreeIPA to use trust to service unix > systems. However, I encountered resistance as some people didn't like > the long username, for example, > username at domain.local@dev1.example.com. ? So I created local accounts > and forced everyone back to FreeIPA users. > > Some people didn't mind the name format and would prefer a single > username everywhere. So now things are a bit cool, am investigating if > these accounts can coexist and would like it to be up to the user's > which account the will use > > When I check id when logged in on with ad account, I don't ? see the > group developer, but see developers at example.local. This is a problem > since I can't assign files to two groups, something I need as they > have files they all have change. I also need both users to have SUDO > access, this is fine as I can just duplicate SUDO commands one for > developers group and another for developers at example.local > > > How would one fix file sharing between ad and FreeIPA users? > > I don't think one can put a group within another group? Or am I wrong > on that? Google results seem negative > > Thanks for advice > > William > > > Check this http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust I think you might want to consider views and override names there. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagemnna at gmail.com Fri Nov 21 01:07:05 2014 From: nagemnna at gmail.com (Megan .) Date: Thu, 20 Nov 2014 20:07:05 -0500 Subject: [Freeipa-users] Setting up clients to use replica server Message-ID: Good Evening! We are using 3.0.0-42 on Centos 6.6. I am not using NTP or DNS (we are not allowed to run these services in our environment.) I configured the replica using the directions at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/installing-replica.html I'm trying to configure my clients to failover to the replica. I believe I have my sssd.conf correct but i can't figure out the proper syntax for the krb5.conf. Is there documentation somewhere that I can use? I tried placing to kdc = in the file with dir1 and dir2, but it didn't work. Any help is greatly appreciated. My sssd.conf [domain/MYDOMAIN.COM] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = MYDOMAIN.COM id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = db2-uat.mydomain.com chpass_provider = ipa ipa_server = _srv_, dir1.mydomain.com, dir2.mydomain.com dns_discovery_domain = MYDOMAIN.COM sudo_provider = ldap ldap_uri = ldap://dir1.mydomain.com, ldap://dir2.mydomain.com ldap_sudo_search_base = ou=sudoers,dc=mydomain,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/db2-uat.mydomain.com ldap_sasl_realm = MYDOMAIN.COM krb5_server = dir1.mydomain.com, dir2.mydomain.com [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = MYDOMAIN.COM [nss] [pam] [sudo] debug_level = 5 [autofs] [ssh] [pac] 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 = MYDOMAIN.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] MYDOMAIN.COM = { kdc = dir1.mydomain.com:88 master_kdc = dir1.mydomain.com:88 admin_server = dir1.mydomain.com:749 default_domain = mydomain.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .mydomain.com = MYDOMAIN.COM mydomain.com = MYDOMAIN.COM [dbmodules] MYDOMAIN.COM = { db_library = ipadb.so } From rolf_16_nufable at yahoo.com Fri Nov 21 02:00:28 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Fri, 21 Nov 2014 02:00:28 +0000 (UTC) Subject: [Freeipa-users] DNS forwarders In-Reply-To: <546DA7A3.1060908@redhat.com> References: <546DA7A3.1060908@redhat.com> Message-ID: <521581051.2919975.1416535228857.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> I have a new question ( stupid question really )? is it required for the IPA server to have internet access? cuz thats my only way to get the time right in my freeipa server.. the timedatectl in fedora20? while using ntp theres some bugs maybe that every after reboot it doesn't automatically run,( even with chkconfig on , even the ntpdate service doesn't run automatically with chkconfig )? TIA? On Thursday, November 20, 2014 12:34 AM, Martin Kosek wrote: On 11/20/2014 08:10 AM, Rolf Nufable wrote: > I've installed freeipa 4.1.1 --setup-dns --no-forwarders so far the installation went well .. but I need to configure freeipa server as a forwarder right? > so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. > after the reboot I couldn't access the web browser. > Any idea on how can I fix this?? > TIA > >? ? ? On Wednesday, November 19, 2014 7:41 PM, Rolf Nufable wrote: >? ? > >? I have a quick question Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? > I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually.. > TIA Forwarders just allows you to configure BIND to forward all requests for zones it does not manage to specified name server. Normally, this is not required if DNS is set correctly and BIND can simply get results by querying from top "." to the required zone (e.g. "example.com."). But in internal networks or special deployments, you need to set up the forwarders, yes. Just make sure they point to some recursive DNS server. More on this topic in this book for example: http://www.zytrax.com/books/dns/ch4/ About your problem - it is probably DNS. Check where your resolv.conf is pointing, check if DNS (named service) is running. Check? that IPA is really running (ipactl status) and you should find where the problem is. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Fri Nov 21 02:15:40 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 21 Nov 2014 03:15:40 +0100 Subject: [Freeipa-users] Primary mail address possible ? Message-ID: Hi Guys, For authenticating a user in Kolab I need uid at sub.domain.local as emailaddress, but as my user needs also name at domain.tld I need to add this as extra mail address. When I add this second email address I cannot login to Kolab anymore as it will use user at domain.tld in the kolab logs. When I remove it it can login again. Removing uid at sub.domain.local and only having name at domain.tld doesn't work either. Anyone an idea how I can set uid at sub.domain.local bind a primary ? Cheers, Matt From mkosek at redhat.com Fri Nov 21 07:24:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Nov 2014 08:24:03 +0100 Subject: [Freeipa-users] DNS forwarders In-Reply-To: <521581051.2919975.1416535228857.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> References: <546DA7A3.1060908@redhat.com> <521581051.2919975.1416535228857.JavaMail.yahoo@jws10699.mail.bf1.yahoo.com> Message-ID: <546EE893.4050005@redhat.com> IPA does not need to have internet access. But if you want to have the IPA server time synchronized, it needs to have access to the NTP server of your choice. Martin On 11/21/2014 03:00 AM, Rolf Nufable wrote: > I have a new question ( stupid question really ) > is it required for the IPA server to have internet access? cuz thats my only way to get the time right in my freeipa server.. the timedatectl in fedora20 > while using ntp theres some bugs maybe that every after reboot it doesn't automatically run,( even with chkconfig on , even the ntpdate service doesn't run automatically with chkconfig ) > TIA > > On Thursday, November 20, 2014 12:34 AM, Martin Kosek wrote: > > > On 11/20/2014 08:10 AM, Rolf Nufable wrote: >> I've installed freeipa 4.1.1 --setup-dns --no-forwarders so far the installation went well .. but I need to configure freeipa server as a forwarder right? >> so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. >> after the reboot I couldn't access the web browser. >> Any idea on how can I fix this?? >> TIA >> >> On Wednesday, November 19, 2014 7:41 PM, Rolf Nufable wrote: >> >> >> I have a quick question Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? >> I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually.. >> TIA > > Forwarders just allows you to configure BIND to forward all requests for zones > it does not manage to specified name server. Normally, this is not required if > DNS is set correctly and BIND can simply get results by querying from top "." > to the required zone (e.g. "example.com."). > > But in internal networks or special deployments, you need to set up the > forwarders, yes. Just make sure they point to some recursive DNS server. More > on this topic in this book for example: > > http://www.zytrax.com/books/dns/ch4/ > > About your problem - it is probably DNS. Check where your resolv.conf is > pointing, check if DNS (named service) is running. Check that IPA is really > running (ipactl status) and you should find where the problem is. > > Martin > > > > From genadipost at gmail.com Fri Nov 21 08:30:17 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 21 Nov 2014 10:30:17 +0200 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546D0B2E.2070007@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> <546D0A73.3080206@martos.bme.hu> <546D0B2E.2070007@redhat.com> Message-ID: > Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) > > Martin Will it be included as a tech preview or fully supported? On 11/19/2014 10:24 PM, Tamas Papp wrote: > > On 11/19/2014 09:29 PM, Martin Kosek wrote: > >> >> Ah, yes. This one is not a problem with the CentOS port, but rather >> existing >> problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all >> platforms, including Fedora 21 and CentOS. >> >> See upstream ticket: >> https://fedorahosted.org/freeipa/ticket/4716 >> >> Until this is fixed, correct workaround is to chown this directory by >> named:named and chmod rights to 0770. >> >> I will with the team when 4.1.2 is about to be released, if it is not >> soon, I >> can just add the patch to the 4.1.1 in Copr repo. >> > > Thanks for all. > > Just a question. My understanding is that 4.x will not hit RH 7 ever. > So for IPA 4.x we have to wait until RH8, am I correct? > > Thanks, > tamas > Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) Martin -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 21 08:39:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Nov 2014 09:39:09 +0100 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> <546D0A73.3080206@martos.bme.hu> <546D0B2E.2070007@redhat.com> Message-ID: <546EFA2D.6070409@redhat.com> On 11/21/2014 09:30 AM, Genadi Postrilko wrote: >> Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - > so you can look forward to that :-) >> >> Martin > > Will it be included as a tech preview or fully supported? You mean if whole IPA will be Tech Preview or Fully Supported? The functionality that was present and supported in RHEL-7.0 of course cannot be suddenly put to Tech Preview. I cannot disclose at this moment which *new* features would be supported and which would be TP, wait and see - but I think this information will be publicly available even in RHEL-7.1 Beta :-) > On 11/19/2014 10:24 PM, Tamas Papp wrote: > >> >> On 11/19/2014 09:29 PM, Martin Kosek wrote: >> >>> >>> Ah, yes. This one is not a problem with the CentOS port, but rather >>> existing >>> problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all >>> platforms, including Fedora 21 and CentOS. >>> >>> See upstream ticket: >>> https://fedorahosted.org/freeipa/ticket/4716 >>> >>> Until this is fixed, correct workaround is to chown this directory by >>> named:named and chmod rights to 0770. >>> >>> I will with the team when 4.1.2 is about to be released, if it is not >>> soon, I >>> can just add the patch to the 4.1.1 in Copr repo. >>> >> >> Thanks for all. >> >> Just a question. My understanding is that 4.x will not hit RH 7 ever. >> So for IPA 4.x we have to wait until RH8, am I correct? >> >> Thanks, >> tamas >> > > Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so > you can look forward to that :-) > > Martin > From sbose at redhat.com Fri Nov 21 08:52:35 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 21 Nov 2014 09:52:35 +0100 Subject: [Freeipa-users] Mixing local FreeIPA users with active directory users In-Reply-To: <546E8A76.6080800@redhat.com> References: <20141121003834.6037651.22833.8974@gmail.com> <546E8A76.6080800@redhat.com> Message-ID: <20141121085235.GH14090@localhost.localdomain> On Thu, Nov 20, 2014 at 07:42:30PM -0500, Dmitri Pal wrote: > On 11/20/2014 07:38 PM, William Muriithi wrote: > >?Hi guys, > > > >I am wondering how one would go about allowing both ad users and FreeIPA > >user to work in harmony. > > > >I recently was able to get FreeIPA to use trust to service unix systems. > >However, I encountered resistance as some people didn't like the long > >username, for example, username at domain.local@dev1.example.com. ? So I > >created local accounts and forced everyone back to FreeIPA users. I'm wondering why you need this very long names with the double @-sign. Typically you should be able to use aduser at AD.DOMAIN or ADSHORT\aduser as you have to do with Windows when accessing trusted forests. > > > >Some people didn't mind the name format and would prefer a single username > >everywhere. So now things are a bit cool, am investigating if these > >accounts can coexist and would like it to be up to the user's which > >account the will use > > > >When I check id when logged in on with ad account, I don't ? see the group > >developer, but see developers at example.local. This is a problem since I > >can't assign files to two groups, something I need as they have files they > >all have change. I also need both users to have SUDO access, this is fine > >as I can just duplicate SUDO commands one for developers group and another > >for developers at example.local > > > > > >How would one fix file sharing between ad and FreeIPA users? You can put AD groups into IPA groups via a special IPA group you can create with the --external option. To this group you can add an AD group and then you can put this group into any other IPA POSIX group. Now you can use this IPA POSIX group to grant access to all IPA and AD users which are members of the related groups. HTH bye, Sumit > > > >I don't think one can put a group within another group? Or am I wrong on > >that? Google results seem negative > > > >Thanks for advice > > > >William > > > > > > > Check this > http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust > I think you might want to consider views and override names there. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 From jhrozek at redhat.com Fri Nov 21 09:42:23 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 21 Nov 2014 10:42:23 +0100 Subject: [Freeipa-users] Setting up clients to use replica server In-Reply-To: References: Message-ID: <20141121094223.GA12319@hendrix.brq.redhat.com> On Thu, Nov 20, 2014 at 08:07:05PM -0500, Megan . wrote: > Good Evening! > > We are using 3.0.0-42 on Centos 6.6. I am not using NTP or DNS (we > are not allowed to run these services in our environment.) > > I configured the replica using the directions at > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/installing-replica.html > > > I'm trying to configure my clients to failover to the replica. I > believe I have my sssd.conf correct but i can't figure out the proper > syntax for the krb5.conf. Is there documentation somewhere that I can > use? I tried placing to kdc = in the file with dir1 and dir2, but it > didn't work. Any help is greatly appreciated. If the use-case is tools like kinit, kpasswd or other tools using libkrb5 to use the same KDCs as sssd, then sssd does that already automatically: https://jhrozek.livejournal.com/4580.html From dbischof at hrz.uni-kassel.de Fri Nov 21 09:59:36 2014 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Fri, 21 Nov 2014 10:59:36 +0100 (CET) Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <546DFF77.7090104@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> <546DFF77.7090104@redhat.com> Message-ID: Hi, On Thu, 20 Nov 2014, thierry bordaz wrote: > On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: >> >> On Thu, 20 Nov 2014, thierry bordaz wrote: >> >>> Server1 successfully replicated to Server2, but Server2 fails to >>> replicated to Server1. >>> >>> The replication Server2->Server1 is done with kerberos authentication. >>> Server1 receives the replication session, successfully identify the >>> replication manager, start to receives replication extop but suddenly >>> closes the connection. >>> >>> >>> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from >>> xxx to yyy >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="krbprincipalname=xxx" >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >>> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >>> nentries=0 etime=0 >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >>> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >>> function error. >>> >>> The reason of this closure is logged in server1 error log. sasl_decode >>> fails to decode a received PDU. >>> >>> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet >>> for connection 2980 >>> >>> I do not know why it fails but I wonder if the received PDU is not larger >>> than the maximum configured value. The attribute nsslapd-maxsasliosize is >>> set to 2Mb by default. Would it be possible to increase its value (5Mb) to >>> see if it has an impact >>> >>> [...] >> >> I set nsslapd-maxsasliosize to 6164480 on both machines, but the problem >> remains. > > The sasl-decode fails but the exact returned value is not logged. With > standard version we may need to attach a debugger and then set a > conditional breakpoint in sasl-decode just after conn->oparams.decode > that will fire if result !=0. Now this can change the dynamic and > possibly prevent the problem to occur again. The other option is to use > an instrumented version to log this value. If I understand the mechanism correctly, Server1 needs to have debug versions of the relevant packages (probably 389-ds-base and cyrus-sasl) installed in order to track down the problem. Unfortunately, my Server1 is in production use - if I break it, my colleagues will grab forks and torches and be after me. A short downtime would be ok, though. Is there something else I could do? Mit freundlichen Gruessen/With best regards, --Daniel. From jcholast at redhat.com Fri Nov 21 10:09:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 11:09:06 +0100 Subject: [Freeipa-users] Antwort: Re: Antwort: Re: Multiple Domains and SSH In-Reply-To: References: <546BC43C.5070305@redhat.com><126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> <546C3E02.9020804@redhat.com> <546DD954.8040801@redhat.com> Message-ID: <546F0F42.4020605@redhat.com> It seems you added "ipaclient.mgmt.hss.int,ipaclient.hss.int" to fqdn, instead of adding "ipaclient.mgmt.hss.int" and "ipaclient.hss.int" separately. Dne 21.11.2014 v 11:05 Christoph Kaminski napsal(a): > with ipa 3.3.0 work your second solution but if I do it then I get > errors in the gui if I go to the hosts settings there > > Error: > ipaclient.mgmt.hss.int,ipaclient.hss.int: host not found > > > > both names are in configured as A Record in dns > > MfG > Christoph Kaminski > > > > Von: Jan Cholasta > An: Christoph Kaminski > Kopie: Jakub Hrozek , Dmitri Pal , > "freeipa-users at redhat.com" > Datum: 20.11.2014 13:08 > Betreff: Re: Antwort: Re: [Freeipa-users] Multiple Domains and SSH > ------------------------------------------------------------------------ > > > > Hi, > > Dne 19.11.2014 v 09:45 Christoph Kaminski napsal(a): > > this is an example of a host here and the ways how can I reach it via > ssh: > > (they are all in dns forward and reverse resolving) > > (note I redacted the hostnames and IP addresses in the output below) > > > > > host host.mgmt > > host.mgmt has address 192.168.1.1 > > host 192.168.1.1 > > 1.1.168.192.in-addr.arpa domain name pointer host.mgmt. > > host host.mydom.int > > host.mydom.int has address 192.168.2.1 > > host 192.168.2.1 > > 1.2.168.192.in-addr.arpa domain name pointer host.mydom.int. > > host host.mydom.net > > host.mydom.net has address 192.168.3.1 > > host 192.168.3.1 > > 1.3.168.192.in-addr.arpa domain name pointer host.mydom.net. > > So it's a host with multiple IP addresses? You have 2 options then: > > 1. Add a host entry with the SSH public key to IPA for each of the > hostnames then, as Dmitri suggested. > > 2. Manually add the additional hostnames to the fqdn attribute of the > host entry using ldapmodify. > > > > > MfG > > Christoph Kaminski > > > > > > > > > > Von: Jan Cholasta > > An: Jakub Hrozek , dpal at redhat.com > > Kopie: freeipa-users at redhat.com > > Datum: 19.11.2014 07:53 > > Betreff: Re: [Freeipa-users] Multiple Domains and SSH > > Gesendet von: freeipa-users-bounces at redhat.com > > ------------------------------------------------------------------------ > > > > > > > > Hi, > > > > Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): > > > > > >> On 18 Nov 2014, at 23:12, Dmitri Pal wrote: > > >> > > >> On 11/18/2014 01:07 AM, Christoph Kaminski wrote: > > >>> Hi > > >>> > > >>> I can reach each host here via ssh on multiple domains: > > >>> > > >>> host.mydom.int > > >>> host mydom.net > > >>> host.mgmt > > >>> > > >>> sss_ssh_knownhostproxy does work only on the domain which I have > > use to register to ipa (mgmt), on the other domains I get ever "The > > authenticity of host 'host.mydom.int ()' > > can't be established."... why? > > > > Because it does not know that the hostnames refer to the same host. > > > > Do you have a reverse DNS record set up for the host? Does it point to > > the same hostname that you used to register the host in IPA? > > > > >>> > > >> > > >> > > >> And other hosts in those domains are not registered? > > >> May be you should try to add a host entry and SSH digest to IPA even > > if they are not enrolled? > > > > This would work too. > > > > >> > > > > > > Maybe Honza would have some tips for debugging... > > > > See pages 13-16 of > > > . > > > > Honza > > > > -- > > Jan Cholasta > > > > -- > > 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 > > > > > > > > www.biotronik.com> > > ------------------------------------------------------------------------ > > *BIOTRONIK - excellence for life* > > Established with the development of the first German pacemaker in 1963, > > BIOTRONIK has upheld the highest quality standards in the fields of > > cardiac rhythm management and vascular intervention in more than 100 > > countries worldwide. We?ve developed advanced technologies and products > > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > > offers the broadest portfolio of cardiac devices with ProMRI?, an > > advanced technology that gives patients access to magnetic resonance > > (MR) scanning. > > ------------------------------------------------------------------------ > > BIOTRONIK SE & Co. KG > > Woermannkehre 1, 12359 Berlin, Germany > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > > > Vertreten durch ihre Komplement?rin: > > BIOTRONIK MT SE > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > > ------------------------------------------------------------------------ > > This e-mail and the information it contains including attachments are > > confidential and meant only for use by the intended recipient(s); > > disclosure or copying is strictly prohibited. If you are not addressed, > > but in the possession of this e-mail, please notify the sender > > immediately and delete the document. > > Honza > > -- > Jan Cholasta > > > > www.biotronik.com > ------------------------------------------------------------------------ > *BIOTRONIK - excellence for life* > Established with the development of the first German pacemaker in 1963, > BIOTRONIK has upheld the highest quality standards in the fields of > cardiac rhythm management and vascular intervention in more than 100 > countries worldwide. We?ve developed advanced technologies and products > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > offers the broadest portfolio of cardiac devices with ProMRI?, an > advanced technology that gives patients access to magnetic resonance > (MR) scanning. > ------------------------------------------------------------------------ > BIOTRONIK SE & Co. KG > Woermannkehre 1, 12359 Berlin, Germany > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > Vertreten durch ihre Komplement?rin: > BIOTRONIK MT SE > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > ------------------------------------------------------------------------ > This e-mail and the information it contains including attachments are > confidential and meant only for use by the intended recipient(s); > disclosure or copying is strictly prohibited. If you are not addressed, > but in the possession of this e-mail, please notify the sender > immediately and delete the document. -- Jan Cholasta From tbordaz at redhat.com Fri Nov 21 10:51:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 21 Nov 2014 11:51:39 +0100 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> <546DFF77.7090104@redhat.com> Message-ID: <546F193B.4020602@redhat.com> On 11/21/2014 10:59 AM, dbischof at hrz.uni-kassel.de wrote: > Hi, > > On Thu, 20 Nov 2014, thierry bordaz wrote: > >> On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: >>> >>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>> >>>> Server1 successfully replicated to Server2, but Server2 fails to >>>> replicated to Server1. >>>> >>>> The replication Server2->Server1 is done with kerberos >>>> authentication. Server1 receives the replication session, >>>> successfully identify the replication manager, start to receives >>>> replication extop but suddenly closes the connection. >>>> >>>> >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from >>>> xxx to yyy >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >>>> nentries=0 etime=0 dn="krbprincipalname=xxx" >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >>>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >>>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >>>> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >>>> nentries=0 etime=0 >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >>>> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >>>> function error. >>>> >>>> The reason of this closure is logged in server1 error log. >>>> sasl_decode fails to decode a received PDU. >>>> >>>> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet >>>> for connection 2980 >>>> >>>> I do not know why it fails but I wonder if the received PDU is not >>>> larger than the maximum configured value. The attribute >>>> nsslapd-maxsasliosize is set to 2Mb by default. Would it be >>>> possible to increase its value (5Mb) to see if it has an impact >>>> >>>> [...] >>> >>> I set nsslapd-maxsasliosize to 6164480 on both machines, but the >>> problem remains. >> >> The sasl-decode fails but the exact returned value is not logged. >> With standard version we may need to attach a debugger and then set a >> conditional breakpoint in sasl-decode just after conn->oparams.decode >> that will fire if result !=0. Now this can change the dynamic and >> possibly prevent the problem to occur again. The other option is to >> use an instrumented version to log this value. > > If I understand the mechanism correctly, Server1 needs to have debug > versions of the relevant packages (probably 389-ds-base and > cyrus-sasl) installed in order to track down the problem. > Unfortunately, my Server1 is in production use - if I break it, my > colleagues will grab forks and torches and be after me. A short > downtime would be ok, though. > > Is there something else I could do? Hello, Sure I do not want to trigger so much trouble ;-) I think my email was not clear. To go further we would need to know the exact reason why sasl_decode fails. I see two options: * Prepare a debug version, that would report in the error logs the returned valud of sasl_decode (when it fails). Except downtime to install the debug version, it has no impact in production. * Do a debug session (gdb) on Server1. The debug session will install a breakpoint at a specific place, let the server run, catch the sasl_decode failure and note the return code, exit from debugger. When the problem occurs, it happens regularly (each 5 seconds) so we should not have to wait long. That means that debugging Server1 should disturb production for 5 to 10 min. A detailed procedure to do the debug session is required. thanks thierry > > > Mit freundlichen Gruessen/With best regards, > > --Daniel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Nov 21 14:50:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 15:50:29 +0100 Subject: [Freeipa-users] Antwort: Re: Antwort: Re: Antwort: Re: Multiple Domains and SSH In-Reply-To: References: <546BC43C.5070305@redhat.com><126E88A1-36D9-475E-9828-A6525FAFF5D2@redhat.com> <546C3E02.9020804@redhat.com> <546DD954.8040801@redhat.com> <546F0F42.4020605@redhat.com> Message-ID: <546F5135.7030306@redhat.com> Right, I forgot that this is the way IPA sent multi-value primary keys before version 4.0, sorry. If you require working web UI, the only alternative is adding a host entry for each hostname then. Dne 21.11.2014 v 13:56 Christoph Kaminski napsal(a): > no have added it in 2 fqdn attributes > > MfG > Christoph Kaminski > > > > Von: Jan Cholasta > An: Christoph Kaminski > Kopie: "freeipa-users at redhat.com" > Datum: 21.11.2014 11:09 > Betreff: Re: Antwort: Re: Antwort: Re: [Freeipa-users] Multiple Domains > and SSH > ------------------------------------------------------------------------ > > > > It seems you added "ipaclient.mgmt.hss.int,ipaclient.hss.int" to fqdn, > instead of adding "ipaclient.mgmt.hss.int" and "ipaclient.hss.int" > separately. > > Dne 21.11.2014 v 11:05 Christoph Kaminski napsal(a): > > with ipa 3.3.0 work your second solution but if I do it then I get > > errors in the gui if I go to the hosts settings there > > > > Error: > > ipaclient.mgmt.hss.int,ipaclient.hss.int: host not found > > > > > > > > both names are in configured as A Record in dns > > > > MfG > > Christoph Kaminski > > > > > > > > Von: Jan Cholasta > > An: Christoph Kaminski > > Kopie: Jakub Hrozek , Dmitri Pal , > > "freeipa-users at redhat.com" > > Datum: 20.11.2014 13:08 > > Betreff: Re: Antwort: Re: [Freeipa-users] Multiple Domains and SSH > > ------------------------------------------------------------------------ > > > > > > > > Hi, > > > > Dne 19.11.2014 v 09:45 Christoph Kaminski napsal(a): > > > this is an example of a host here and the ways how can I reach it via > > ssh: > > > (they are all in dns forward and reverse resolving) > > > > (note I redacted the hostnames and IP addresses in the output below) > > > > > > > > host host.mgmt > > > host.mgmt has address 192.168.1.1 > > > host 192.168.1.1 > > > 1.1.168.192.in-addr.arpa domain name pointer host.mgmt. > > > host host.mydom.int > > > host.mydom.int has address 192.168.2.1 > > > host 192.168.2.1 > > > 1.2.168.192.in-addr.arpa domain name pointer host.mydom.int. > > > host host.mydom.net > > > host.mydom.net has address 192.168.3.1 > > > host 192.168.3.1 > > > 1.3.168.192.in-addr.arpa domain name pointer host.mydom.net. > > > > So it's a host with multiple IP addresses? You have 2 options then: > > > > 1. Add a host entry with the SSH public key to IPA for each of the > > hostnames then, as Dmitri suggested. > > > > 2. Manually add the additional hostnames to the fqdn attribute of the > > host entry using ldapmodify. > > > > > > > > MfG > > > Christoph Kaminski > > > > > > > > > > > > > > > Von: Jan Cholasta > > > An: Jakub Hrozek , dpal at redhat.com > > > Kopie: freeipa-users at redhat.com > > > Datum: 19.11.2014 07:53 > > > Betreff: Re: [Freeipa-users] Multiple Domains and SSH > > > Gesendet von: freeipa-users-bounces at redhat.com > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > Hi, > > > > > > Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): > > > > > > > >> On 18 Nov 2014, at 23:12, Dmitri Pal wrote: > > > >> > > > >> On 11/18/2014 01:07 AM, Christoph Kaminski wrote: > > > >>> Hi > > > >>> > > > >>> I can reach each host here via ssh on multiple domains: > > > >>> > > > >>> host.mydom.int > > > >>> host mydom.net > > > >>> host.mgmt > > > >>> > > > >>> sss_ssh_knownhostproxy does work only on the domain which I have > > > use to register to ipa (mgmt), on the other domains I get ever "The > > > authenticity of host 'host.mydom.int ()' > > > can't be established."... why? > > > > > > Because it does not know that the hostnames refer to the same host. > > > > > > Do you have a reverse DNS record set up for the host? Does it point to > > > the same hostname that you used to register the host in IPA? > > > > > > >>> > > > >> > > > >> > > > >> And other hosts in those domains are not registered? > > > >> May be you should try to add a host entry and SSH digest to > IPA even > > > if they are not enrolled? > > > > > > This would work too. > > > > > > >> > > > > > > > > Maybe Honza would have some tips for debugging... > > > > > > See pages 13-16 of > > > > > > . > > > > > > Honza > > > > > > -- > > > Jan Cholasta > > > > > > -- > > > 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 > > > > > > > > > > > > www.biotronik.com > > > > > ------------------------------------------------------------------------ > > > *BIOTRONIK - excellence for life* > > > Established with the development of the first German pacemaker in > 1963, > > > BIOTRONIK has upheld the highest quality standards in the fields of > > > cardiac rhythm management and vascular intervention in more than 100 > > > countries worldwide. We?ve developed advanced technologies and > products > > > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > > > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > > > offers the broadest portfolio of cardiac devices with ProMRI?, an > > > advanced technology that gives patients access to magnetic resonance > > > (MR) scanning. > > > > ------------------------------------------------------------------------ > > > BIOTRONIK SE & Co. KG > > > Woermannkehre 1, 12359 Berlin, Germany > > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > > > > > Vertreten durch ihre Komplement?rin: > > > BIOTRONIK MT SE > > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > > > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > > > > ------------------------------------------------------------------------ > > > This e-mail and the information it contains including attachments are > > > confidential and meant only for use by the intended recipient(s); > > > disclosure or copying is strictly prohibited. If you are not > addressed, > > > but in the possession of this e-mail, please notify the sender > > > immediately and delete the document. > > > > Honza > > > > -- > > Jan Cholasta > > > > > > > > www.biotronik.com> > > ------------------------------------------------------------------------ > > *BIOTRONIK - excellence for life* > > Established with the development of the first German pacemaker in 1963, > > BIOTRONIK has upheld the highest quality standards in the fields of > > cardiac rhythm management and vascular intervention in more than 100 > > countries worldwide. We?ve developed advanced technologies and products > > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > > offers the broadest portfolio of cardiac devices with ProMRI?, an > > advanced technology that gives patients access to magnetic resonance > > (MR) scanning. > > ------------------------------------------------------------------------ > > BIOTRONIK SE & Co. KG > > Woermannkehre 1, 12359 Berlin, Germany > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > > > Vertreten durch ihre Komplement?rin: > > BIOTRONIK MT SE > > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > > ------------------------------------------------------------------------ > > This e-mail and the information it contains including attachments are > > confidential and meant only for use by the intended recipient(s); > > disclosure or copying is strictly prohibited. If you are not addressed, > > but in the possession of this e-mail, please notify the sender > > immediately and delete the document. > > > -- > Jan Cholasta > > > > www.biotronik.com > ------------------------------------------------------------------------ > *BIOTRONIK - excellence for life* > Established with the development of the first German pacemaker in 1963, > BIOTRONIK has upheld the highest quality standards in the fields of > cardiac rhythm management and vascular intervention in more than 100 > countries worldwide. We?ve developed advanced technologies and products > such as BIOTRONIK Home Monitoring?, Closed Loop Stimulation (CLS) and > Orsiro, the industry?s first hybrid drug eluting stent. BIOTRONIK also > offers the broadest portfolio of cardiac devices with ProMRI?, an > advanced technology that gives patients access to magnetic resonance > (MR) scanning. > ------------------------------------------------------------------------ > BIOTRONIK SE & Co. KG > Woermannkehre 1, 12359 Berlin, Germany > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 > > Vertreten durch ihre Komplement?rin: > BIOTRONIK MT SE > Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B > Gesch?ftsf?hrende Direktoren: Christoph B?hmer, Dr. Lothar Krings > ------------------------------------------------------------------------ > This e-mail and the information it contains including attachments are > confidential and meant only for use by the intended recipient(s); > disclosure or copying is strictly prohibited. If you are not addressed, > but in the possession of this e-mail, please notify the sender > immediately and delete the document. -- Jan Cholasta From rmeggins at redhat.com Fri Nov 21 15:49:04 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 21 Nov 2014 09:49:04 -0600 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <546F193B.4020602@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> <546DFF77.7090104@redhat.com> <546F193B.4020602@redhat.com> Message-ID: <546F5EF0.2020608@redhat.com> On 11/21/2014 04:51 AM, thierry bordaz wrote: > On 11/21/2014 10:59 AM, dbischof at hrz.uni-kassel.de wrote: >> Hi, >> >> On Thu, 20 Nov 2014, thierry bordaz wrote: >> >>> On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: >>>> >>>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>>> >>>>> Server1 successfully replicated to Server2, but Server2 fails to >>>>> replicated to Server1. >>>>> >>>>> The replication Server2->Server1 is done with kerberos >>>>> authentication. Server1 receives the replication session, >>>>> successfully identify the replication manager, start to receives >>>>> replication extop but suddenly closes the connection. >>>>> >>>>> >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection >>>>> from >>>>> xxx to yyy >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >>>>> nentries=0 etime=0 dn="krbprincipalname=xxx" >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >>>>> filter="(objectClass=*)" attrs="supportedControl >>>>> supportedExtension" >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >>>>> filter="(objectClass=*)" attrs="supportedControl >>>>> supportedExtension" >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >>>>> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >>>>> nentries=0 etime=0 >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >>>>> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >>>>> function error. >>>>> >>>>> The reason of this closure is logged in server1 error log. >>>>> sasl_decode fails to decode a received PDU. >>>>> >>>>> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet >>>>> for connection 2980 >>>>> >>>>> I do not know why it fails but I wonder if the received PDU is not >>>>> larger than the maximum configured value. The attribute >>>>> nsslapd-maxsasliosize is set to 2Mb by default. Would it be >>>>> possible to increase its value (5Mb) to see if it has an impact >>>>> >>>>> [...] >>>> >>>> I set nsslapd-maxsasliosize to 6164480 on both machines, but the >>>> problem remains. >>> >>> The sasl-decode fails but the exact returned value is not logged. >>> With standard version we may need to attach a debugger and then set >>> a conditional breakpoint in sasl-decode just after >>> conn->oparams.decode that will fire if result !=0. Now this can >>> change the dynamic and possibly prevent the problem to occur again. >>> The other option is to use an instrumented version to log this value. >> >> If I understand the mechanism correctly, Server1 needs to have debug >> versions of the relevant packages (probably 389-ds-base and >> cyrus-sasl) installed in order to track down the problem. >> Unfortunately, my Server1 is in production use - if I break it, my >> colleagues will grab forks and torches and be after me. A short >> downtime would be ok, though. >> >> Is there something else I could do? > > Hello, > > Sure I do not want to trigger so much trouble ;-) > > > I think my email was not clear. To go further we would need to know > the exact reason why sasl_decode fails. I see two options: > > * Prepare a debug version, that would report in the error logs the > returned valud of sasl_decode (when it fails). Except downtime to > install the debug version, it has no impact in production. > > * Do a debug session (gdb) on Server1. The debug session will > install a breakpoint at a specific place, let the server run, > catch the sasl_decode failure and note the return code, exit from > debugger. > When the problem occurs, it happens regularly (each 5 seconds) so > we should not have to wait long. > That means that debugging Server1 should disturb production for 5 > to 10 min. > A detailed procedure to do the debug session is required. > For starters: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes Since this is IPA you will need debuginfo packages for ipa and slapi-nis in addition to the ones for 389. Take a look at the Debugging Hangs section where it describes how to use gdb to get a stack trace. If you can use that gdb command to get a stack trace with the full debugging symbols (and if you don't know what that means, just post the redacted stack trace somewhere and provide us with a link to it), then you should be all ready to do a gdb session to reproduce the error and "catch it in the act". > * > > thanks > thierry > >> >> >> Mit freundlichen Gruessen/With best regards, >> >> --Daniel. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Fri Nov 21 19:48:34 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 21 Nov 2014 21:48:34 +0200 Subject: [Freeipa-users] freeipa-server from copr repo In-Reply-To: <546EFA2D.6070409@redhat.com> References: <546C72F7.1050507@martos.bme.hu> <546C76EB.9070707@redhat.com> <149c7b32da8.2772.b4c2854741c50caf28b8595b5e98fc2d@martos.bme.hu> <546CC400.3060902@redhat.com> <1192413147.12483987.1416415272263.JavaMail.zimbra@redhat.com> <546CFC58.5090001@martos.bme.hu> <546CFDAC.8020608@redhat.com> <546D0A73.3080206@martos.bme.hu> <546D0B2E.2070007@redhat.com> <546EFA2D.6070409@redhat.com> Message-ID: Ok :) Thank you for the response. 2014-11-21 10:39 GMT+02:00 Martin Kosek : > On 11/21/2014 09:30 AM, Genadi Postrilko wrote: > >> Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - > > so you can look forward to that :-) > >> > >> Martin > > > > Will it be included as a tech preview or fully supported? > > You mean if whole IPA will be Tech Preview or Fully Supported? The > functionality that was present and supported in RHEL-7.0 of course cannot > be > suddenly put to Tech Preview. > > I cannot disclose at this moment which *new* features would be supported > and > which would be TP, wait and see - but I think this information will be > publicly > available even in RHEL-7.1 Beta :-) > > > On 11/19/2014 10:24 PM, Tamas Papp wrote: > > > >> > >> On 11/19/2014 09:29 PM, Martin Kosek wrote: > >> > >>> > >>> Ah, yes. This one is not a problem with the CentOS port, but rather > >>> existing > >>> problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all > >>> platforms, including Fedora 21 and CentOS. > >>> > >>> See upstream ticket: > >>> https://fedorahosted.org/freeipa/ticket/4716 > >>> > >>> Until this is fixed, correct workaround is to chown this directory by > >>> named:named and chmod rights to 0770. > >>> > >>> I will with the team when 4.1.2 is about to be released, if it is not > >>> soon, I > >>> can just add the patch to the 4.1.1 in Copr repo. > >>> > >> > >> Thanks for all. > >> > >> Just a question. My understanding is that 4.x will not hit RH 7 ever. > >> So for IPA 4.x we have to wait until RH8, am I correct? > >> > >> Thanks, > >> tamas > >> > > > > Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - > so > > you can look forward to that :-) > > > > Martin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 21 22:42:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Nov 2014 17:42:35 -0500 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: Message-ID: <546FBFDB.4080405@redhat.com> On 11/20/2014 09:15 PM, Matt . wrote: > Hi Guys, > > For authenticating a user in Kolab I need uid at sub.domain.local as > emailaddress, but as my user needs also name at domain.tld I need to add > this as extra mail address. User needs it where? How Kolab integration is configured? > > When I add this second email address I cannot login to Kolab anymore > as it will use user at domain.tld in the kolab logs. When I remove it it > can login again. > > Removing uid at sub.domain.local and only having name at domain.tld doesn't > work either. > > Anyone an idea how I can set uid at sub.domain.local bind a primary ? > > Cheers, > > Matt > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Fri Nov 21 23:04:25 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 00:04:25 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: <546FBFDB.4080405@redhat.com> References: <546FBFDB.4080405@redhat.com> Message-ID: Hi Dimitri, What do you mean by how ? Can you be more specific what you want to know ? 2014-11-21 23:42 GMT+01:00 Dmitri Pal : > On 11/20/2014 09:15 PM, Matt . wrote: >> >> Hi Guys, >> >> For authenticating a user in Kolab I need uid at sub.domain.local as >> emailaddress, but as my user needs also name at domain.tld I need to add >> this as extra mail address. > > > User needs it where? > How Kolab integration is configured? > >> >> When I add this second email address I cannot login to Kolab anymore >> as it will use user at domain.tld in the kolab logs. When I remove it it >> can login again. >> >> Removing uid at sub.domain.local and only having name at domain.tld doesn't >> work either. >> >> Anyone an idea how I can set uid at sub.domain.local bind a primary ? >> >> Cheers, >> >> Matt >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 From dpal at redhat.com Fri Nov 21 23:31:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Nov 2014 18:31:35 -0500 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> Message-ID: <546FCB57.7070302@redhat.com> On 11/21/2014 06:04 PM, Matt . wrote: > Hi Dimitri, > > What do you mean by how ? Can you be more specific what you want to know ? How Kolab is connecting to IPA? LDAP ? Kerberos? Direcly from Kolab? Using SSO? Using SSSD and Apache module integration like this http://www.freeipa.org/page/Web_App_Authentication? In some other way? What is the configuration? How the second mail addressed is supposed to be used? What are the applications that need to see/access it? How are they configured? LDAP? SSSD? > > > > 2014-11-21 23:42 GMT+01:00 Dmitri Pal : >> On 11/20/2014 09:15 PM, Matt . wrote: >>> Hi Guys, >>> >>> For authenticating a user in Kolab I need uid at sub.domain.local as >>> emailaddress, but as my user needs also name at domain.tld I need to add >>> this as extra mail address. >> >> User needs it where? >> How Kolab integration is configured? >> >>> When I add this second email address I cannot login to Kolab anymore >>> as it will use user at domain.tld in the kolab logs. When I remove it it >>> can login again. >>> >>> Removing uid at sub.domain.local and only having name at domain.tld doesn't >>> work either. >>> >>> Anyone an idea how I can set uid at sub.domain.local bind a primary ? >>> >>> Cheers, >>> >>> Matt >>> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Fri Nov 21 23:42:50 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 00:42:50 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: <546FCB57.7070302@redhat.com> References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> Message-ID: Hi Dimitri, All I can say about that is that it's configured and uses ldap this this added to ldap: [root at kolab roundcubemail]# ldapsearch -x -h localhost -D "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # kolab, config dn: cn=kolab,cn=config objectClass: top objectClass: extensibleobject cn: kolab # example.org, kolab, config dn: associateddomain=example.org,cn=kolab,cn=config objectClass: top objectClass: domainrelatedobject objectClass: inetdomain associatedDomain: example.org associatedDomain: dc=internal,dc=local inetDomainBaseDN: dc=internal,dc=local # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 kolab_auth.inc.php 'Kolab Auth', 'hosts' => Array('172.16.xx.xx'), 'port' => 389, 'use_tls' => false, 'user_specific' => false, 'base_dn' => 'cn=accounts,dc=domain,dc=local', 'bind_dn' => 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', 'bind_pass' => 'xxxxxx', 'writable' => false, 'ldap_version' => 3, // using LDAPv3 'fieldmap' => Array( 'name' => 'displayname', 'email' => 'mail', 'email:alias' => 'alias', 'role' => 'nsroledn', ), 'sort' => 'displayname', 'scope' => 'sub', 'filter' => '(objectClass=*)', 'fuzzy_search' => true, 'sizelimit' => '0', 'timelimit' => '0', 'groups' => Array( 'base_dn' => 'cn=groups,dc=domain,dc=local', 'filter' => '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', 'object_classes' => Array('top', 'groupOfUniqueNames'), 'member_attr' => 'uniqueMember', ), ); // This will overwrite defined filter $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . '(|(uid=%u)(mail=%fu)(alias=%fu)))'; // Use this fields (from fieldmap configuration) to get authentication ID $config['kolab_auth_login'] = 'email'; // Use this fields (from fieldmap configuration) for default identity $config['kolab_auth_name'] = 'name'; $config['kolab_auth_alias'] = 'alias'; $config['kolab_auth_email'] = 'email'; if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) { // Login and password of the admin user. Enables "Login As" feature. $config['kolab_auth_admin_login'] = 'admin'; $config['kolab_auth_admin_password'] = 'xxxxxx'; $config['kolab_auth_auditlog'] = true; } // Administrative role field (from fieldmap configuration) which must be filled with // specified value which adds privilege to login as another user. $config['kolab_auth_role'] = 'role'; $config['kolab_auth_role_value'] = 'cn=kolab-admin,dc=domain,dc=local'; // Administrative group name to which user must be assigned to // which adds privilege to login as another user. $config['kolab_auth_group'] = 'Kolab Helpdesk'; if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . '/' . basename(__FILE__))) { include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . '/' . basename(__FILE__)); } ?> Does this help you some ? 2014-11-22 0:31 GMT+01:00 Dmitri Pal : > On 11/21/2014 06:04 PM, Matt . wrote: >> >> Hi Dimitri, >> >> What do you mean by how ? Can you be more specific what you want to know ? > > > How Kolab is connecting to IPA? > LDAP ? Kerberos? Direcly from Kolab? Using SSO? Using SSSD and Apache module > integration like this http://www.freeipa.org/page/Web_App_Authentication? > In some other way? > > What is the configuration? > > How the second mail addressed is supposed to be used? > What are the applications that need to see/access it? > How are they configured? LDAP? SSSD? > > > >> >> >> >> 2014-11-21 23:42 GMT+01:00 Dmitri Pal : >>> >>> On 11/20/2014 09:15 PM, Matt . wrote: >>>> >>>> Hi Guys, >>>> >>>> For authenticating a user in Kolab I need uid at sub.domain.local as >>>> emailaddress, but as my user needs also name at domain.tld I need to add >>>> this as extra mail address. >>> >>> >>> User needs it where? >>> How Kolab integration is configured? >>> >>>> When I add this second email address I cannot login to Kolab anymore >>>> as it will use user at domain.tld in the kolab logs. When I remove it it >>>> can login again. >>>> >>>> Removing uid at sub.domain.local and only having name at domain.tld doesn't >>>> work either. >>>> >>>> Anyone an idea how I can set uid at sub.domain.local bind a primary ? >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> -- >>> 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 > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From dpal at redhat.com Fri Nov 21 23:51:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Nov 2014 18:51:25 -0500 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> Message-ID: <546FCFFD.3010202@redhat.com> On 11/21/2014 06:42 PM, Matt . wrote: > Hi Dimitri, > > All I can say about that is that it's configured and uses ldap this > this added to ldap: > > [root at kolab roundcubemail]# ldapsearch -x -h localhost -D > "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # kolab, config > dn: cn=kolab,cn=config > objectClass: top > objectClass: extensibleobject > cn: kolab > > # example.org, kolab, config > dn: associateddomain=example.org,cn=kolab,cn=config > objectClass: top > objectClass: domainrelatedobject > objectClass: inetdomain > associatedDomain: example.org > associatedDomain: dc=internal,dc=local > inetDomainBaseDN: dc=internal,dc=local > > # search result > search: 2 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > > kolab_auth.inc.php > > > // The id of the LDAP address book (which refers to the > rcmail_config['ldap_public']) > // or complete addressbook definition array. > $config['kolab_auth_addressbook'] = Array( > 'name' => 'Kolab Auth', > 'hosts' => Array('172.16.xx.xx'), > 'port' => 389, > 'use_tls' => false, > 'user_specific' => false, > 'base_dn' => 'cn=accounts,dc=domain,dc=local', > 'bind_dn' => > 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', > 'bind_pass' => 'xxxxxx', > 'writable' => false, > 'ldap_version' => 3, // using LDAPv3 > 'fieldmap' => Array( > 'name' => 'displayname', > 'email' => 'mail', Here you can use uid instead of mail. Then user will be able to login into Kolab with a simple name instead of the longer mail. Then you would be able to put name at domain.tld into the mail attribute. It seems that Kolab assumes that mail is a single valued attribute in the directory while in general it is not the case. So the best would be to use come other attribute for login. HTH. > 'email:alias' => 'alias', > 'role' => 'nsroledn', > ), > 'sort' => 'displayname', > 'scope' => 'sub', > 'filter' => '(objectClass=*)', > 'fuzzy_search' => true, > 'sizelimit' => '0', > 'timelimit' => '0', > 'groups' => Array( > 'base_dn' => 'cn=groups,dc=domain,dc=local', > 'filter' => > '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', > 'object_classes' => Array('top', 'groupOfUniqueNames'), > 'member_attr' => 'uniqueMember', > ), > ); > > > // This will overwrite defined filter > $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . > '(|(uid=%u)(mail=%fu)(alias=%fu)))'; > > // Use this fields (from fieldmap configuration) to get authentication ID > $config['kolab_auth_login'] = 'email'; > > // Use this fields (from fieldmap configuration) for default identity > $config['kolab_auth_name'] = 'name'; > $config['kolab_auth_alias'] = 'alias'; > $config['kolab_auth_email'] = 'email'; > > if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) { > > // Login and password of the admin user. Enables "Login As" feature. > $config['kolab_auth_admin_login'] = 'admin'; > $config['kolab_auth_admin_password'] = 'xxxxxx'; > > $config['kolab_auth_auditlog'] = true; > } > > // Administrative role field (from fieldmap configuration) which > must be filled with > // specified value which adds privilege to login as another user. > $config['kolab_auth_role'] = 'role'; > $config['kolab_auth_role_value'] = 'cn=kolab-admin,dc=domain,dc=local'; > > // Administrative group name to which user must be assigned to > // which adds privilege to login as another user. > $config['kolab_auth_group'] = 'Kolab Helpdesk'; > > if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . > '/' . basename(__FILE__))) { > include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . > '/' . basename(__FILE__)); > } > > ?> > > Does this help you some ? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Sat Nov 22 00:12:31 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 01:12:31 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: <546FCFFD.3010202@redhat.com> References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> Message-ID: HI Dimitri, Thanks, but it seems following the kolab devs that if kolab cannot determine the base dn, the other two do not matter. So what would you change exactly ? There might be need changed more. I hope we can get this fixed ! Thanks, Matt 2014-11-22 0:51 GMT+01:00 Dmitri Pal : > On 11/21/2014 06:42 PM, Matt . wrote: >> >> Hi Dimitri, >> >> All I can say about that is that it's configured and uses ldap this >> this added to ldap: >> >> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >> "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # kolab, config >> dn: cn=kolab,cn=config >> objectClass: top >> objectClass: extensibleobject >> cn: kolab >> >> # example.org, kolab, config >> dn: associateddomain=example.org,cn=kolab,cn=config >> objectClass: top >> objectClass: domainrelatedobject >> objectClass: inetdomain >> associatedDomain: example.org >> associatedDomain: dc=internal,dc=local >> inetDomainBaseDN: dc=internal,dc=local >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 3 >> # numEntries: 2 >> >> >> kolab_auth.inc.php >> >> > >> // The id of the LDAP address book (which refers to the >> rcmail_config['ldap_public']) >> // or complete addressbook definition array. >> $config['kolab_auth_addressbook'] = Array( >> 'name' => 'Kolab Auth', >> 'hosts' => Array('172.16.xx.xx'), >> 'port' => 389, >> 'use_tls' => false, >> 'user_specific' => false, >> 'base_dn' => 'cn=accounts,dc=domain,dc=local', >> 'bind_dn' => >> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >> 'bind_pass' => 'xxxxxx', >> 'writable' => false, >> 'ldap_version' => 3, // using LDAPv3 >> 'fieldmap' => Array( >> 'name' => 'displayname', >> 'email' => 'mail', > > > Here you can use uid instead of mail. > Then user will be able to login into Kolab with a simple name instead of the > longer mail. > Then you would be able to put name at domain.tld into the mail attribute. > > It seems that Kolab assumes that mail is a single valued attribute in the > directory while in general it is not the case. > So the best would be to use come other attribute for login. > > HTH. > >> 'email:alias' => 'alias', >> 'role' => 'nsroledn', >> ), >> 'sort' => 'displayname', >> 'scope' => 'sub', >> 'filter' => '(objectClass=*)', >> 'fuzzy_search' => true, >> 'sizelimit' => '0', >> 'timelimit' => '0', >> 'groups' => Array( >> 'base_dn' => 'cn=groups,dc=domain,dc=local', >> 'filter' => >> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >> 'object_classes' => Array('top', >> 'groupOfUniqueNames'), >> 'member_attr' => 'uniqueMember', >> ), >> ); >> >> >> // This will overwrite defined filter >> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . >> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >> >> // Use this fields (from fieldmap configuration) to get >> authentication ID >> $config['kolab_auth_login'] = 'email'; >> >> // Use this fields (from fieldmap configuration) for default identity >> $config['kolab_auth_name'] = 'name'; >> $config['kolab_auth_alias'] = 'alias'; >> $config['kolab_auth_email'] = 'email'; >> >> if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) { >> >> // Login and password of the admin user. Enables "Login As" >> feature. >> $config['kolab_auth_admin_login'] = 'admin'; >> $config['kolab_auth_admin_password'] = 'xxxxxx'; >> >> $config['kolab_auth_auditlog'] = true; >> } >> >> // Administrative role field (from fieldmap configuration) which >> must be filled with >> // specified value which adds privilege to login as another user. >> $config['kolab_auth_role'] = 'role'; >> $config['kolab_auth_role_value'] = >> 'cn=kolab-admin,dc=domain,dc=local'; >> >> // Administrative group name to which user must be assigned to >> // which adds privilege to login as another user. >> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >> >> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >> '/' . basename(__FILE__))) { >> include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >> '/' . basename(__FILE__)); >> } >> >> ?> >> >> Does this help you some ? > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From dpal at redhat.com Sat Nov 22 00:45:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Nov 2014 19:45:15 -0500 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> Message-ID: <546FDC9B.6060709@redhat.com> On 11/21/2014 07:12 PM, Matt . wrote: > HI Dimitri, > > Thanks, but it seems following the kolab devs that if kolab cannot > determine the base dn, the other two do not matter. > > So what would you change exactly ? I assume you use IPA as an LDAP server. In the Kolab config I would change 'email' => 'mail', to 'email' => 'uid', In IPA I would use "name" in the uid and name at domain in email (as IPA creates) by default. and then try to log into Kolab using name. So for me it would look like this: In ipa: uid: dpal mail: dpal at mydomain.com > > There might be need changed more. > > I hope we can get this fixed ! > > Thanks, > > Matt > > 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >> On 11/21/2014 06:42 PM, Matt . wrote: >>> Hi Dimitri, >>> >>> All I can say about that is that it's configured and uses ldap this >>> this added to ldap: >>> >>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>> "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # kolab, config >>> dn: cn=kolab,cn=config >>> objectClass: top >>> objectClass: extensibleobject >>> cn: kolab >>> >>> # example.org, kolab, config >>> dn: associateddomain=example.org,cn=kolab,cn=config >>> objectClass: top >>> objectClass: domainrelatedobject >>> objectClass: inetdomain >>> associatedDomain: example.org >>> associatedDomain: dc=internal,dc=local >>> inetDomainBaseDN: dc=internal,dc=local >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 3 >>> # numEntries: 2 >>> >>> >>> kolab_auth.inc.php >>> >>> >> >>> // The id of the LDAP address book (which refers to the >>> rcmail_config['ldap_public']) >>> // or complete addressbook definition array. >>> $config['kolab_auth_addressbook'] = Array( >>> 'name' => 'Kolab Auth', >>> 'hosts' => Array('172.16.xx.xx'), >>> 'port' => 389, >>> 'use_tls' => false, >>> 'user_specific' => false, >>> 'base_dn' => 'cn=accounts,dc=domain,dc=local', >>> 'bind_dn' => >>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>> 'bind_pass' => 'xxxxxx', >>> 'writable' => false, >>> 'ldap_version' => 3, // using LDAPv3 >>> 'fieldmap' => Array( >>> 'name' => 'displayname', >>> 'email' => 'mail', >> >> Here you can use uid instead of mail. >> Then user will be able to login into Kolab with a simple name instead of the >> longer mail. >> Then you would be able to put name at domain.tld into the mail attribute. >> >> It seems that Kolab assumes that mail is a single valued attribute in the >> directory while in general it is not the case. >> So the best would be to use come other attribute for login. >> >> HTH. >> >>> 'email:alias' => 'alias', >>> 'role' => 'nsroledn', >>> ), >>> 'sort' => 'displayname', >>> 'scope' => 'sub', >>> 'filter' => '(objectClass=*)', >>> 'fuzzy_search' => true, >>> 'sizelimit' => '0', >>> 'timelimit' => '0', >>> 'groups' => Array( >>> 'base_dn' => 'cn=groups,dc=domain,dc=local', >>> 'filter' => >>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>> 'object_classes' => Array('top', >>> 'groupOfUniqueNames'), >>> 'member_attr' => 'uniqueMember', >>> ), >>> ); >>> >>> >>> // This will overwrite defined filter >>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . >>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>> >>> // Use this fields (from fieldmap configuration) to get >>> authentication ID >>> $config['kolab_auth_login'] = 'email'; >>> >>> // Use this fields (from fieldmap configuration) for default identity >>> $config['kolab_auth_name'] = 'name'; >>> $config['kolab_auth_alias'] = 'alias'; >>> $config['kolab_auth_email'] = 'email'; >>> >>> if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) { >>> >>> // Login and password of the admin user. Enables "Login As" >>> feature. >>> $config['kolab_auth_admin_login'] = 'admin'; >>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>> >>> $config['kolab_auth_auditlog'] = true; >>> } >>> >>> // Administrative role field (from fieldmap configuration) which >>> must be filled with >>> // specified value which adds privilege to login as another user. >>> $config['kolab_auth_role'] = 'role'; >>> $config['kolab_auth_role_value'] = >>> 'cn=kolab-admin,dc=domain,dc=local'; >>> >>> // Administrative group name to which user must be assigned to >>> // which adds privilege to login as another user. >>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>> >>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>> '/' . basename(__FILE__))) { >>> include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>> '/' . basename(__FILE__)); >>> } >>> >>> ?> >>> >>> Does this help you some ? >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Sat Nov 22 00:55:38 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 01:55:38 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: <546FDC9B.6060709@redhat.com> References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> <546FDC9B.6060709@redhat.com> Message-ID: HI, Yes and that doesn't let me login... that's the issue. 2014-11-22 1:45 GMT+01:00 Dmitri Pal : > On 11/21/2014 07:12 PM, Matt . wrote: >> >> HI Dimitri, >> >> Thanks, but it seems following the kolab devs that if kolab cannot >> determine the base dn, the other two do not matter. >> >> So what would you change exactly ? > > > I assume you use IPA as an LDAP server. > In the Kolab config I would change > > 'email' => 'mail', > > to > > 'email' => 'uid', > > > In IPA I would use "name" in the uid and name at domain in email (as IPA > creates) by default. > and then try to log into Kolab using name. > > So for me it would look like this: > > In ipa: > uid: dpal > mail: dpal at mydomain.com > > >> >> There might be need changed more. >> >> I hope we can get this fixed ! >> >> Thanks, >> >> Matt >> >> 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >>> >>> On 11/21/2014 06:42 PM, Matt . wrote: >>>> >>>> Hi Dimitri, >>>> >>>> All I can say about that is that it's configured and uses ldap this >>>> this added to ldap: >>>> >>>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>>> "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree >>>> # filter: (objectclass=*) >>>> # requesting: ALL >>>> # >>>> >>>> # kolab, config >>>> dn: cn=kolab,cn=config >>>> objectClass: top >>>> objectClass: extensibleobject >>>> cn: kolab >>>> >>>> # example.org, kolab, config >>>> dn: associateddomain=example.org,cn=kolab,cn=config >>>> objectClass: top >>>> objectClass: domainrelatedobject >>>> objectClass: inetdomain >>>> associatedDomain: example.org >>>> associatedDomain: dc=internal,dc=local >>>> inetDomainBaseDN: dc=internal,dc=local >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 3 >>>> # numEntries: 2 >>>> >>>> >>>> kolab_auth.inc.php >>>> >>>> >>> >>>> // The id of the LDAP address book (which refers to the >>>> rcmail_config['ldap_public']) >>>> // or complete addressbook definition array. >>>> $config['kolab_auth_addressbook'] = Array( >>>> 'name' => 'Kolab Auth', >>>> 'hosts' => Array('172.16.xx.xx'), >>>> 'port' => 389, >>>> 'use_tls' => false, >>>> 'user_specific' => false, >>>> 'base_dn' => >>>> 'cn=accounts,dc=domain,dc=local', >>>> 'bind_dn' => >>>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>>> 'bind_pass' => 'xxxxxx', >>>> 'writable' => false, >>>> 'ldap_version' => 3, // using LDAPv3 >>>> 'fieldmap' => Array( >>>> 'name' => 'displayname', >>>> 'email' => 'mail', >>> >>> >>> Here you can use uid instead of mail. >>> Then user will be able to login into Kolab with a simple name instead of >>> the >>> longer mail. >>> Then you would be able to put name at domain.tld into the mail attribute. >>> >>> It seems that Kolab assumes that mail is a single valued attribute in the >>> directory while in general it is not the case. >>> So the best would be to use come other attribute for login. >>> >>> HTH. >>> >>>> 'email:alias' => 'alias', >>>> 'role' => 'nsroledn', >>>> ), >>>> 'sort' => 'displayname', >>>> 'scope' => 'sub', >>>> 'filter' => '(objectClass=*)', >>>> 'fuzzy_search' => true, >>>> 'sizelimit' => '0', >>>> 'timelimit' => '0', >>>> 'groups' => Array( >>>> 'base_dn' => 'cn=groups,dc=domain,dc=local', >>>> 'filter' => >>>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>>> 'object_classes' => Array('top', >>>> 'groupOfUniqueNames'), >>>> 'member_attr' => 'uniqueMember', >>>> ), >>>> ); >>>> >>>> >>>> // This will overwrite defined filter >>>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . >>>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>>> >>>> // Use this fields (from fieldmap configuration) to get >>>> authentication ID >>>> $config['kolab_auth_login'] = 'email'; >>>> >>>> // Use this fields (from fieldmap configuration) for default >>>> identity >>>> $config['kolab_auth_name'] = 'name'; >>>> $config['kolab_auth_alias'] = 'alias'; >>>> $config['kolab_auth_email'] = 'email'; >>>> >>>> if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) >>>> { >>>> >>>> // Login and password of the admin user. Enables "Login As" >>>> feature. >>>> $config['kolab_auth_admin_login'] = 'admin'; >>>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>>> >>>> $config['kolab_auth_auditlog'] = true; >>>> } >>>> >>>> // Administrative role field (from fieldmap configuration) which >>>> must be filled with >>>> // specified value which adds privilege to login as another user. >>>> $config['kolab_auth_role'] = 'role'; >>>> $config['kolab_auth_role_value'] = >>>> 'cn=kolab-admin,dc=domain,dc=local'; >>>> >>>> // Administrative group name to which user must be assigned to >>>> // which adds privilege to login as another user. >>>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>>> >>>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>> '/' . basename(__FILE__))) { >>>> include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>> '/' . basename(__FILE__)); >>>> } >>>> >>>> ?> >>>> >>>> Does this help you some ? >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From yamakasi.014 at gmail.com Sat Nov 22 00:57:57 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 01:57:57 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> <546FDC9B.6060709@redhat.com> Message-ID: I need to say, saslauth caches it, didn't restart that one actually as it's kinda late! 2014-11-22 1:55 GMT+01:00 Matt . : > HI, > > Yes and that doesn't let me login... that's the issue. > > 2014-11-22 1:45 GMT+01:00 Dmitri Pal : >> On 11/21/2014 07:12 PM, Matt . wrote: >>> >>> HI Dimitri, >>> >>> Thanks, but it seems following the kolab devs that if kolab cannot >>> determine the base dn, the other two do not matter. >>> >>> So what would you change exactly ? >> >> >> I assume you use IPA as an LDAP server. >> In the Kolab config I would change >> >> 'email' => 'mail', >> >> to >> >> 'email' => 'uid', >> >> >> In IPA I would use "name" in the uid and name at domain in email (as IPA >> creates) by default. >> and then try to log into Kolab using name. >> >> So for me it would look like this: >> >> In ipa: >> uid: dpal >> mail: dpal at mydomain.com >> >> >>> >>> There might be need changed more. >>> >>> I hope we can get this fixed ! >>> >>> Thanks, >>> >>> Matt >>> >>> 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >>>> >>>> On 11/21/2014 06:42 PM, Matt . wrote: >>>>> >>>>> Hi Dimitri, >>>>> >>>>> All I can say about that is that it's configured and uses ldap this >>>>> this added to ldap: >>>>> >>>>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>>>> "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base with scope subtree >>>>> # filter: (objectclass=*) >>>>> # requesting: ALL >>>>> # >>>>> >>>>> # kolab, config >>>>> dn: cn=kolab,cn=config >>>>> objectClass: top >>>>> objectClass: extensibleobject >>>>> cn: kolab >>>>> >>>>> # example.org, kolab, config >>>>> dn: associateddomain=example.org,cn=kolab,cn=config >>>>> objectClass: top >>>>> objectClass: domainrelatedobject >>>>> objectClass: inetdomain >>>>> associatedDomain: example.org >>>>> associatedDomain: dc=internal,dc=local >>>>> inetDomainBaseDN: dc=internal,dc=local >>>>> >>>>> # search result >>>>> search: 2 >>>>> result: 0 Success >>>>> >>>>> # numResponses: 3 >>>>> # numEntries: 2 >>>>> >>>>> >>>>> kolab_auth.inc.php >>>>> >>>>> >>>> >>>>> // The id of the LDAP address book (which refers to the >>>>> rcmail_config['ldap_public']) >>>>> // or complete addressbook definition array. >>>>> $config['kolab_auth_addressbook'] = Array( >>>>> 'name' => 'Kolab Auth', >>>>> 'hosts' => Array('172.16.xx.xx'), >>>>> 'port' => 389, >>>>> 'use_tls' => false, >>>>> 'user_specific' => false, >>>>> 'base_dn' => >>>>> 'cn=accounts,dc=domain,dc=local', >>>>> 'bind_dn' => >>>>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>>>> 'bind_pass' => 'xxxxxx', >>>>> 'writable' => false, >>>>> 'ldap_version' => 3, // using LDAPv3 >>>>> 'fieldmap' => Array( >>>>> 'name' => 'displayname', >>>>> 'email' => 'mail', >>>> >>>> >>>> Here you can use uid instead of mail. >>>> Then user will be able to login into Kolab with a simple name instead of >>>> the >>>> longer mail. >>>> Then you would be able to put name at domain.tld into the mail attribute. >>>> >>>> It seems that Kolab assumes that mail is a single valued attribute in the >>>> directory while in general it is not the case. >>>> So the best would be to use come other attribute for login. >>>> >>>> HTH. >>>> >>>>> 'email:alias' => 'alias', >>>>> 'role' => 'nsroledn', >>>>> ), >>>>> 'sort' => 'displayname', >>>>> 'scope' => 'sub', >>>>> 'filter' => '(objectClass=*)', >>>>> 'fuzzy_search' => true, >>>>> 'sizelimit' => '0', >>>>> 'timelimit' => '0', >>>>> 'groups' => Array( >>>>> 'base_dn' => 'cn=groups,dc=domain,dc=local', >>>>> 'filter' => >>>>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>>>> 'object_classes' => Array('top', >>>>> 'groupOfUniqueNames'), >>>>> 'member_attr' => 'uniqueMember', >>>>> ), >>>>> ); >>>>> >>>>> >>>>> // This will overwrite defined filter >>>>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . >>>>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>>>> >>>>> // Use this fields (from fieldmap configuration) to get >>>>> authentication ID >>>>> $config['kolab_auth_login'] = 'email'; >>>>> >>>>> // Use this fields (from fieldmap configuration) for default >>>>> identity >>>>> $config['kolab_auth_name'] = 'name'; >>>>> $config['kolab_auth_alias'] = 'alias'; >>>>> $config['kolab_auth_email'] = 'email'; >>>>> >>>>> if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) >>>>> { >>>>> >>>>> // Login and password of the admin user. Enables "Login As" >>>>> feature. >>>>> $config['kolab_auth_admin_login'] = 'admin'; >>>>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>>>> >>>>> $config['kolab_auth_auditlog'] = true; >>>>> } >>>>> >>>>> // Administrative role field (from fieldmap configuration) which >>>>> must be filled with >>>>> // specified value which adds privilege to login as another user. >>>>> $config['kolab_auth_role'] = 'role'; >>>>> $config['kolab_auth_role_value'] = >>>>> 'cn=kolab-admin,dc=domain,dc=local'; >>>>> >>>>> // Administrative group name to which user must be assigned to >>>>> // which adds privilege to login as another user. >>>>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>>>> >>>>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>>> '/' . basename(__FILE__))) { >>>>> include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>>> '/' . basename(__FILE__)); >>>>> } >>>>> >>>>> ?> >>>>> >>>>> Does this help you some ? >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> From dpal at redhat.com Sat Nov 22 01:14:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Nov 2014 20:14:42 -0500 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> <546FDC9B.6060709@redhat.com> Message-ID: <546FE382.9020607@redhat.com> On 11/21/2014 07:57 PM, Matt . wrote: > I need to say, saslauth caches it, didn't restart that one actually as > it's kinda late! So when you restarted did it work or still no luck? > > 2014-11-22 1:55 GMT+01:00 Matt . : >> HI, >> >> Yes and that doesn't let me login... that's the issue. >> >> 2014-11-22 1:45 GMT+01:00 Dmitri Pal : >>> On 11/21/2014 07:12 PM, Matt . wrote: >>>> HI Dimitri, >>>> >>>> Thanks, but it seems following the kolab devs that if kolab cannot >>>> determine the base dn, the other two do not matter. >>>> >>>> So what would you change exactly ? >>> >>> I assume you use IPA as an LDAP server. >>> In the Kolab config I would change >>> >>> 'email' => 'mail', >>> >>> to >>> >>> 'email' => 'uid', >>> >>> >>> In IPA I would use "name" in the uid and name at domain in email (as IPA >>> creates) by default. >>> and then try to log into Kolab using name. >>> >>> So for me it would look like this: >>> >>> In ipa: >>> uid: dpal >>> mail: dpal at mydomain.com >>> >>> >>>> There might be need changed more. >>>> >>>> I hope we can get this fixed ! >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >>>>> On 11/21/2014 06:42 PM, Matt . wrote: >>>>>> Hi Dimitri, >>>>>> >>>>>> All I can say about that is that it's configured and uses ldap this >>>>>> this added to ldap: >>>>>> >>>>>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>>>>> "cn=Directory Manager" -w Welcome2KolabSystems -b "cn=kolab,cn=config" >>>>>> # extended LDIF >>>>>> # >>>>>> # LDAPv3 >>>>>> # base with scope subtree >>>>>> # filter: (objectclass=*) >>>>>> # requesting: ALL >>>>>> # >>>>>> >>>>>> # kolab, config >>>>>> dn: cn=kolab,cn=config >>>>>> objectClass: top >>>>>> objectClass: extensibleobject >>>>>> cn: kolab >>>>>> >>>>>> # example.org, kolab, config >>>>>> dn: associateddomain=example.org,cn=kolab,cn=config >>>>>> objectClass: top >>>>>> objectClass: domainrelatedobject >>>>>> objectClass: inetdomain >>>>>> associatedDomain: example.org >>>>>> associatedDomain: dc=internal,dc=local >>>>>> inetDomainBaseDN: dc=internal,dc=local >>>>>> >>>>>> # search result >>>>>> search: 2 >>>>>> result: 0 Success >>>>>> >>>>>> # numResponses: 3 >>>>>> # numEntries: 2 >>>>>> >>>>>> >>>>>> kolab_auth.inc.php >>>>>> >>>>>> >>>>> >>>>>> // The id of the LDAP address book (which refers to the >>>>>> rcmail_config['ldap_public']) >>>>>> // or complete addressbook definition array. >>>>>> $config['kolab_auth_addressbook'] = Array( >>>>>> 'name' => 'Kolab Auth', >>>>>> 'hosts' => Array('172.16.xx.xx'), >>>>>> 'port' => 389, >>>>>> 'use_tls' => false, >>>>>> 'user_specific' => false, >>>>>> 'base_dn' => >>>>>> 'cn=accounts,dc=domain,dc=local', >>>>>> 'bind_dn' => >>>>>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>>>>> 'bind_pass' => 'xxxxxx', >>>>>> 'writable' => false, >>>>>> 'ldap_version' => 3, // using LDAPv3 >>>>>> 'fieldmap' => Array( >>>>>> 'name' => 'displayname', >>>>>> 'email' => 'mail', >>>>> >>>>> Here you can use uid instead of mail. >>>>> Then user will be able to login into Kolab with a simple name instead of >>>>> the >>>>> longer mail. >>>>> Then you would be able to put name at domain.tld into the mail attribute. >>>>> >>>>> It seems that Kolab assumes that mail is a single valued attribute in the >>>>> directory while in general it is not the case. >>>>> So the best would be to use come other attribute for login. >>>>> >>>>> HTH. >>>>> >>>>>> 'email:alias' => 'alias', >>>>>> 'role' => 'nsroledn', >>>>>> ), >>>>>> 'sort' => 'displayname', >>>>>> 'scope' => 'sub', >>>>>> 'filter' => '(objectClass=*)', >>>>>> 'fuzzy_search' => true, >>>>>> 'sizelimit' => '0', >>>>>> 'timelimit' => '0', >>>>>> 'groups' => Array( >>>>>> 'base_dn' => 'cn=groups,dc=domain,dc=local', >>>>>> 'filter' => >>>>>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>>>>> 'object_classes' => Array('top', >>>>>> 'groupOfUniqueNames'), >>>>>> 'member_attr' => 'uniqueMember', >>>>>> ), >>>>>> ); >>>>>> >>>>>> >>>>>> // This will overwrite defined filter >>>>>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' . >>>>>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>>>>> >>>>>> // Use this fields (from fieldmap configuration) to get >>>>>> authentication ID >>>>>> $config['kolab_auth_login'] = 'email'; >>>>>> >>>>>> // Use this fields (from fieldmap configuration) for default >>>>>> identity >>>>>> $config['kolab_auth_name'] = 'name'; >>>>>> $config['kolab_auth_alias'] = 'alias'; >>>>>> $config['kolab_auth_email'] = 'email'; >>>>>> >>>>>> if (preg_match('/\/helpdesk-login\//', $_SERVER["REQUEST_URI"]) ) >>>>>> { >>>>>> >>>>>> // Login and password of the admin user. Enables "Login As" >>>>>> feature. >>>>>> $config['kolab_auth_admin_login'] = 'admin'; >>>>>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>>>>> >>>>>> $config['kolab_auth_auditlog'] = true; >>>>>> } >>>>>> >>>>>> // Administrative role field (from fieldmap configuration) which >>>>>> must be filled with >>>>>> // specified value which adds privilege to login as another user. >>>>>> $config['kolab_auth_role'] = 'role'; >>>>>> $config['kolab_auth_role_value'] = >>>>>> 'cn=kolab-admin,dc=domain,dc=local'; >>>>>> >>>>>> // Administrative group name to which user must be assigned to >>>>>> // which adds privilege to login as another user. >>>>>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>>>>> >>>>>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>>>> '/' . basename(__FILE__))) { >>>>>> include_once(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] . >>>>>> '/' . basename(__FILE__)); >>>>>> } >>>>>> >>>>>> ?> >>>>>> >>>>>> Does this help you some ? >>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Sat Nov 22 01:23:15 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 02:23:15 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: <546FE382.9020607@redhat.com> References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> <546FDC9B.6060709@redhat.com> <546FE382.9020607@redhat.com> Message-ID: Hi that wasn't quite clear from me, yes I can login thanks for that! But now I get an error on the associated domain: postmap: dict_ldap_connect: Cached connection handle for LDAP source /etc/postfix/ldap/mydestination.cf postmap: dict_ldap_lookup: /etc/postfix/ldap/mydestination.cf: Searching with filter (&(associatedDomain=user at domain.tld)) postmap: dict_ldap_get_values[1]: Search found 0 match(es) postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values postmap: dict_ldap_lookup: Search returned nothing postmap: dict_ldap_close: Closed connection handle for LDAP source /etc/postfix/ldap/mydestination.cf But when I do a postmap check on this cf with domain.tld that gives a match, as it should... So that might need some modification ? 2014-11-22 2:14 GMT+01:00 Dmitri Pal : > On 11/21/2014 07:57 PM, Matt . wrote: >> >> I need to say, saslauth caches it, didn't restart that one actually as >> it's kinda late! > > > So when you restarted did it work or still no luck? > > >> >> 2014-11-22 1:55 GMT+01:00 Matt . : >>> >>> HI, >>> >>> Yes and that doesn't let me login... that's the issue. >>> >>> 2014-11-22 1:45 GMT+01:00 Dmitri Pal : >>>> >>>> On 11/21/2014 07:12 PM, Matt . wrote: >>>>> >>>>> HI Dimitri, >>>>> >>>>> Thanks, but it seems following the kolab devs that if kolab cannot >>>>> determine the base dn, the other two do not matter. >>>>> >>>>> So what would you change exactly ? >>>> >>>> >>>> I assume you use IPA as an LDAP server. >>>> In the Kolab config I would change >>>> >>>> 'email' => 'mail', >>>> >>>> to >>>> >>>> 'email' => 'uid', >>>> >>>> >>>> In IPA I would use "name" in the uid and name at domain in email (as IPA >>>> creates) by default. >>>> and then try to log into Kolab using name. >>>> >>>> So for me it would look like this: >>>> >>>> In ipa: >>>> uid: dpal >>>> mail: dpal at mydomain.com >>>> >>>> >>>>> There might be need changed more. >>>>> >>>>> I hope we can get this fixed ! >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >>>>>> >>>>>> On 11/21/2014 06:42 PM, Matt . wrote: >>>>>>> >>>>>>> Hi Dimitri, >>>>>>> >>>>>>> All I can say about that is that it's configured and uses ldap this >>>>>>> this added to ldap: >>>>>>> >>>>>>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>>>>>> "cn=Directory Manager" -w Welcome2KolabSystems -b >>>>>>> "cn=kolab,cn=config" >>>>>>> # extended LDIF >>>>>>> # >>>>>>> # LDAPv3 >>>>>>> # base with scope subtree >>>>>>> # filter: (objectclass=*) >>>>>>> # requesting: ALL >>>>>>> # >>>>>>> >>>>>>> # kolab, config >>>>>>> dn: cn=kolab,cn=config >>>>>>> objectClass: top >>>>>>> objectClass: extensibleobject >>>>>>> cn: kolab >>>>>>> >>>>>>> # example.org, kolab, config >>>>>>> dn: associateddomain=example.org,cn=kolab,cn=config >>>>>>> objectClass: top >>>>>>> objectClass: domainrelatedobject >>>>>>> objectClass: inetdomain >>>>>>> associatedDomain: example.org >>>>>>> associatedDomain: dc=internal,dc=local >>>>>>> inetDomainBaseDN: dc=internal,dc=local >>>>>>> >>>>>>> # search result >>>>>>> search: 2 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # numResponses: 3 >>>>>>> # numEntries: 2 >>>>>>> >>>>>>> >>>>>>> kolab_auth.inc.php >>>>>>> >>>>>>> >>>>>> >>>>>>> // The id of the LDAP address book (which refers to the >>>>>>> rcmail_config['ldap_public']) >>>>>>> // or complete addressbook definition array. >>>>>>> $config['kolab_auth_addressbook'] = Array( >>>>>>> 'name' => 'Kolab Auth', >>>>>>> 'hosts' => Array('172.16.xx.xx'), >>>>>>> 'port' => 389, >>>>>>> 'use_tls' => false, >>>>>>> 'user_specific' => false, >>>>>>> 'base_dn' => >>>>>>> 'cn=accounts,dc=domain,dc=local', >>>>>>> 'bind_dn' => >>>>>>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>>>>>> 'bind_pass' => 'xxxxxx', >>>>>>> 'writable' => false, >>>>>>> 'ldap_version' => 3, // using LDAPv3 >>>>>>> 'fieldmap' => Array( >>>>>>> 'name' => 'displayname', >>>>>>> 'email' => 'mail', >>>>>> >>>>>> >>>>>> Here you can use uid instead of mail. >>>>>> Then user will be able to login into Kolab with a simple name instead >>>>>> of >>>>>> the >>>>>> longer mail. >>>>>> Then you would be able to put name at domain.tld into the mail attribute. >>>>>> >>>>>> It seems that Kolab assumes that mail is a single valued attribute in >>>>>> the >>>>>> directory while in general it is not the case. >>>>>> So the best would be to use come other attribute for login. >>>>>> >>>>>> HTH. >>>>>> >>>>>>> 'email:alias' => 'alias', >>>>>>> 'role' => 'nsroledn', >>>>>>> ), >>>>>>> 'sort' => 'displayname', >>>>>>> 'scope' => 'sub', >>>>>>> 'filter' => '(objectClass=*)', >>>>>>> 'fuzzy_search' => true, >>>>>>> 'sizelimit' => '0', >>>>>>> 'timelimit' => '0', >>>>>>> 'groups' => Array( >>>>>>> 'base_dn' => >>>>>>> 'cn=groups,dc=domain,dc=local', >>>>>>> 'filter' => >>>>>>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>>>>>> 'object_classes' => Array('top', >>>>>>> 'groupOfUniqueNames'), >>>>>>> 'member_attr' => 'uniqueMember', >>>>>>> ), >>>>>>> ); >>>>>>> >>>>>>> >>>>>>> // This will overwrite defined filter >>>>>>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' >>>>>>> . >>>>>>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>>>>>> >>>>>>> // Use this fields (from fieldmap configuration) to get >>>>>>> authentication ID >>>>>>> $config['kolab_auth_login'] = 'email'; >>>>>>> >>>>>>> // Use this fields (from fieldmap configuration) for default >>>>>>> identity >>>>>>> $config['kolab_auth_name'] = 'name'; >>>>>>> $config['kolab_auth_alias'] = 'alias'; >>>>>>> $config['kolab_auth_email'] = 'email'; >>>>>>> >>>>>>> if (preg_match('/\/helpdesk-login\//', >>>>>>> $_SERVER["REQUEST_URI"]) ) >>>>>>> { >>>>>>> >>>>>>> // Login and password of the admin user. Enables "Login >>>>>>> As" >>>>>>> feature. >>>>>>> $config['kolab_auth_admin_login'] = 'admin'; >>>>>>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>>>>>> >>>>>>> $config['kolab_auth_auditlog'] = true; >>>>>>> } >>>>>>> >>>>>>> // Administrative role field (from fieldmap configuration) >>>>>>> which >>>>>>> must be filled with >>>>>>> // specified value which adds privilege to login as another >>>>>>> user. >>>>>>> $config['kolab_auth_role'] = 'role'; >>>>>>> $config['kolab_auth_role_value'] = >>>>>>> 'cn=kolab-admin,dc=domain,dc=local'; >>>>>>> >>>>>>> // Administrative group name to which user must be assigned to >>>>>>> // which adds privilege to login as another user. >>>>>>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>>>>>> >>>>>>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] >>>>>>> . >>>>>>> '/' . basename(__FILE__))) { >>>>>>> include_once(RCUBE_CONFIG_DIR . '/' . >>>>>>> $_SERVER["HTTP_HOST"] . >>>>>>> '/' . basename(__FILE__)); >>>>>>> } >>>>>>> >>>>>>> ?> >>>>>>> >>>>>>> Does this help you some ? >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Dmitri Pal >>>>>> >>>>>> Sr. Engineering Manager IdM portfolio >>>>>> Red Hat, Inc. >>>>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From yamakasi.014 at gmail.com Sat Nov 22 01:36:39 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 22 Nov 2014 02:36:39 +0100 Subject: [Freeipa-users] Primary mail address possible ? In-Reply-To: References: <546FBFDB.4080405@redhat.com> <546FCB57.7070302@redhat.com> <546FCFFD.3010202@redhat.com> <546FDC9B.6060709@redhat.com> <546FE382.9020607@redhat.com> Message-ID: Hi, OK got it working by changing the mailadres to uid at domain.tld Actually no IPA question, but you might know, my email is not delivered in one file /var/mail/uid instead of the maildir format it should do. At least it arrives well! Thanks 2014-11-22 2:23 GMT+01:00 Matt . : > Hi that wasn't quite clear from me, yes I can login thanks for that! > > But now I get an error on the associated domain: > > postmap: dict_ldap_connect: Cached connection handle for LDAP source > /etc/postfix/ldap/mydestination.cf > postmap: dict_ldap_lookup: /etc/postfix/ldap/mydestination.cf: > Searching with filter (&(associatedDomain=user at domain.tld)) > postmap: dict_ldap_get_values[1]: Search found 0 match(es) > postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values > postmap: dict_ldap_lookup: Search returned nothing > postmap: dict_ldap_close: Closed connection handle for LDAP source > /etc/postfix/ldap/mydestination.cf > > But when I do a postmap check on this cf with domain.tld that gives a > match, as it should... > > So that might need some modification ? > > 2014-11-22 2:14 GMT+01:00 Dmitri Pal : >> On 11/21/2014 07:57 PM, Matt . wrote: >>> >>> I need to say, saslauth caches it, didn't restart that one actually as >>> it's kinda late! >> >> >> So when you restarted did it work or still no luck? >> >> >>> >>> 2014-11-22 1:55 GMT+01:00 Matt . : >>>> >>>> HI, >>>> >>>> Yes and that doesn't let me login... that's the issue. >>>> >>>> 2014-11-22 1:45 GMT+01:00 Dmitri Pal : >>>>> >>>>> On 11/21/2014 07:12 PM, Matt . wrote: >>>>>> >>>>>> HI Dimitri, >>>>>> >>>>>> Thanks, but it seems following the kolab devs that if kolab cannot >>>>>> determine the base dn, the other two do not matter. >>>>>> >>>>>> So what would you change exactly ? >>>>> >>>>> >>>>> I assume you use IPA as an LDAP server. >>>>> In the Kolab config I would change >>>>> >>>>> 'email' => 'mail', >>>>> >>>>> to >>>>> >>>>> 'email' => 'uid', >>>>> >>>>> >>>>> In IPA I would use "name" in the uid and name at domain in email (as IPA >>>>> creates) by default. >>>>> and then try to log into Kolab using name. >>>>> >>>>> So for me it would look like this: >>>>> >>>>> In ipa: >>>>> uid: dpal >>>>> mail: dpal at mydomain.com >>>>> >>>>> >>>>>> There might be need changed more. >>>>>> >>>>>> I hope we can get this fixed ! >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2014-11-22 0:51 GMT+01:00 Dmitri Pal : >>>>>>> >>>>>>> On 11/21/2014 06:42 PM, Matt . wrote: >>>>>>>> >>>>>>>> Hi Dimitri, >>>>>>>> >>>>>>>> All I can say about that is that it's configured and uses ldap this >>>>>>>> this added to ldap: >>>>>>>> >>>>>>>> [root at kolab roundcubemail]# ldapsearch -x -h localhost -D >>>>>>>> "cn=Directory Manager" -w Welcome2KolabSystems -b >>>>>>>> "cn=kolab,cn=config" >>>>>>>> # extended LDIF >>>>>>>> # >>>>>>>> # LDAPv3 >>>>>>>> # base with scope subtree >>>>>>>> # filter: (objectclass=*) >>>>>>>> # requesting: ALL >>>>>>>> # >>>>>>>> >>>>>>>> # kolab, config >>>>>>>> dn: cn=kolab,cn=config >>>>>>>> objectClass: top >>>>>>>> objectClass: extensibleobject >>>>>>>> cn: kolab >>>>>>>> >>>>>>>> # example.org, kolab, config >>>>>>>> dn: associateddomain=example.org,cn=kolab,cn=config >>>>>>>> objectClass: top >>>>>>>> objectClass: domainrelatedobject >>>>>>>> objectClass: inetdomain >>>>>>>> associatedDomain: example.org >>>>>>>> associatedDomain: dc=internal,dc=local >>>>>>>> inetDomainBaseDN: dc=internal,dc=local >>>>>>>> >>>>>>>> # search result >>>>>>>> search: 2 >>>>>>>> result: 0 Success >>>>>>>> >>>>>>>> # numResponses: 3 >>>>>>>> # numEntries: 2 >>>>>>>> >>>>>>>> >>>>>>>> kolab_auth.inc.php >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> // The id of the LDAP address book (which refers to the >>>>>>>> rcmail_config['ldap_public']) >>>>>>>> // or complete addressbook definition array. >>>>>>>> $config['kolab_auth_addressbook'] = Array( >>>>>>>> 'name' => 'Kolab Auth', >>>>>>>> 'hosts' => Array('172.16.xx.xx'), >>>>>>>> 'port' => 389, >>>>>>>> 'use_tls' => false, >>>>>>>> 'user_specific' => false, >>>>>>>> 'base_dn' => >>>>>>>> 'cn=accounts,dc=domain,dc=local', >>>>>>>> 'bind_dn' => >>>>>>>> 'uid=admin,cn=users,cn=accounts,dc=domain,dc=local', >>>>>>>> 'bind_pass' => 'xxxxxx', >>>>>>>> 'writable' => false, >>>>>>>> 'ldap_version' => 3, // using LDAPv3 >>>>>>>> 'fieldmap' => Array( >>>>>>>> 'name' => 'displayname', >>>>>>>> 'email' => 'mail', >>>>>>> >>>>>>> >>>>>>> Here you can use uid instead of mail. >>>>>>> Then user will be able to login into Kolab with a simple name instead >>>>>>> of >>>>>>> the >>>>>>> longer mail. >>>>>>> Then you would be able to put name at domain.tld into the mail attribute. >>>>>>> >>>>>>> It seems that Kolab assumes that mail is a single valued attribute in >>>>>>> the >>>>>>> directory while in general it is not the case. >>>>>>> So the best would be to use come other attribute for login. >>>>>>> >>>>>>> HTH. >>>>>>> >>>>>>>> 'email:alias' => 'alias', >>>>>>>> 'role' => 'nsroledn', >>>>>>>> ), >>>>>>>> 'sort' => 'displayname', >>>>>>>> 'scope' => 'sub', >>>>>>>> 'filter' => '(objectClass=*)', >>>>>>>> 'fuzzy_search' => true, >>>>>>>> 'sizelimit' => '0', >>>>>>>> 'timelimit' => '0', >>>>>>>> 'groups' => Array( >>>>>>>> 'base_dn' => >>>>>>>> 'cn=groups,dc=domain,dc=local', >>>>>>>> 'filter' => >>>>>>>> '(|(objectclass=groupofuniquenames)(objectclass=groupofurls))', >>>>>>>> 'object_classes' => Array('top', >>>>>>>> 'groupOfUniqueNames'), >>>>>>>> 'member_attr' => 'uniqueMember', >>>>>>>> ), >>>>>>>> ); >>>>>>>> >>>>>>>> >>>>>>>> // This will overwrite defined filter >>>>>>>> $config['kolab_auth_filter'] = '(&' . '(objectclass=inetuser)' >>>>>>>> . >>>>>>>> '(|(uid=%u)(mail=%fu)(alias=%fu)))'; >>>>>>>> >>>>>>>> // Use this fields (from fieldmap configuration) to get >>>>>>>> authentication ID >>>>>>>> $config['kolab_auth_login'] = 'email'; >>>>>>>> >>>>>>>> // Use this fields (from fieldmap configuration) for default >>>>>>>> identity >>>>>>>> $config['kolab_auth_name'] = 'name'; >>>>>>>> $config['kolab_auth_alias'] = 'alias'; >>>>>>>> $config['kolab_auth_email'] = 'email'; >>>>>>>> >>>>>>>> if (preg_match('/\/helpdesk-login\//', >>>>>>>> $_SERVER["REQUEST_URI"]) ) >>>>>>>> { >>>>>>>> >>>>>>>> // Login and password of the admin user. Enables "Login >>>>>>>> As" >>>>>>>> feature. >>>>>>>> $config['kolab_auth_admin_login'] = 'admin'; >>>>>>>> $config['kolab_auth_admin_password'] = 'xxxxxx'; >>>>>>>> >>>>>>>> $config['kolab_auth_auditlog'] = true; >>>>>>>> } >>>>>>>> >>>>>>>> // Administrative role field (from fieldmap configuration) >>>>>>>> which >>>>>>>> must be filled with >>>>>>>> // specified value which adds privilege to login as another >>>>>>>> user. >>>>>>>> $config['kolab_auth_role'] = 'role'; >>>>>>>> $config['kolab_auth_role_value'] = >>>>>>>> 'cn=kolab-admin,dc=domain,dc=local'; >>>>>>>> >>>>>>>> // Administrative group name to which user must be assigned to >>>>>>>> // which adds privilege to login as another user. >>>>>>>> $config['kolab_auth_group'] = 'Kolab Helpdesk'; >>>>>>>> >>>>>>>> if (file_exists(RCUBE_CONFIG_DIR . '/' . $_SERVER["HTTP_HOST"] >>>>>>>> . >>>>>>>> '/' . basename(__FILE__))) { >>>>>>>> include_once(RCUBE_CONFIG_DIR . '/' . >>>>>>>> $_SERVER["HTTP_HOST"] . >>>>>>>> '/' . basename(__FILE__)); >>>>>>>> } >>>>>>>> >>>>>>>> ?> >>>>>>>> >>>>>>>> Does this help you some ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thank you, >>>>>>> Dmitri Pal >>>>>>> >>>>>>> Sr. Engineering Manager IdM portfolio >>>>>>> Red Hat, Inc. >>>>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> From outbackdingo at gmail.com Sat Nov 22 03:43:53 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Sat, 22 Nov 2014 14:43:53 +1100 Subject: [Freeipa-users] Unable to retrieve CA chain: mismatched tag: line 29, column 2 Message-ID: Fresh Fedora 21 Server, did the yum update -y after install then ran ipa-server-install -a 123XXX123 --hostname=ipa1.domain.com -r DOMAIN.COM -p 123XXX123 -n domain.com -U --setup-dns --forwarder=8.8.8.8 --forwarder=8.8.4.4 and got BIND DNS server will be configured to serve IPA domain with: Forwarders: 8.8.8.8, 8.8.4.4 Reverse zone(s): 70.168.192.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance [3/38]: adding default schema [4/38]: enabling memberof plugin [5/38]: enabling winsync plugin [6/38]: configuring replication version plugin [7/38]: enabling IPA enrollment plugin [8/38]: enabling ldapi [9/38]: configuring uniqueness plugin [10/38]: configuring uuid plugin [11/38]: configuring modrdn plugin [12/38]: configuring DNS plugin [13/38]: enabling entryUSN plugin [14/38]: configuring lockout plugin [15/38]: creating indices [16/38]: enabling referential integrity plugin [17/38]: configuring certmap.conf [18/38]: configure autobind for root [19/38]: configure new location for managed entries [20/38]: configure dirsrv ccache [21/38]: enable SASL mapping fallback [22/38]: restarting directory server [23/38]: adding default layout [24/38]: adding delegation layout [25/38]: creating container for managed entries [26/38]: configuring user private groups [27/38]: configuring netgroups from hostgroups [28/38]: creating default Sudo bind user [29/38]: creating default Auto Member layout [30/38]: adding range check plugin [31/38]: creating default HBAC rule allow_all [32/38]: initializing group membership [33/38]: adding master entry [34/38]: configuring Posix uid/gid generation [35/38]: adding replication acis [36/38]: enabling compatibility plugin [37/38]: tuning directory server [38/38]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/27]: creating certificate server user [2/27]: configuring certificate server instance [3/27]: stopping certificate server instance to update CS.cfg [4/27]: backing up CS.cfg [5/27]: disabling nonces [6/27]: set up CRL publishing [7/27]: enable PKIX certificate path discovery and validation [8/27]: starting certificate server instance [9/27]: creating RA agent certificate database [10/27]: importing CA chain to RA certificate database [error] RuntimeError: Unable to retrieve CA chain: mismatched tag: line 29, column 2 Unable to retrieve CA chain: mismatched tag: line 29, column 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Sat Nov 22 04:15:26 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Sat, 22 Nov 2014 15:15:26 +1100 Subject: [Freeipa-users] Unable to retrieve CA chain: mismatched tag: line 29, column 2 In-Reply-To: References: Message-ID: RECALL.... it works as long as another app isnt in the way :) disregard On Sat, Nov 22, 2014 at 2:43 PM, Outback Dingo wrote: > Fresh Fedora 21 Server, did the yum update -y after install > then ran > > ipa-server-install -a 123XXX123 --hostname=ipa1.domain.com -r DOMAIN.COM > -p 123XXX123 -n domain.com -U --setup-dns --forwarder=8.8.8.8 > --forwarder=8.8.4.4 > > and got > > BIND DNS server will be configured to serve IPA domain with: > Forwarders: 8.8.8.8, 8.8.4.4 > Reverse zone(s): 70.168.192.in-addr.arpa. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/38]: creating directory server user > [2/38]: creating directory server instance > [3/38]: adding default schema > [4/38]: enabling memberof plugin > [5/38]: enabling winsync plugin > [6/38]: configuring replication version plugin > [7/38]: enabling IPA enrollment plugin > [8/38]: enabling ldapi > [9/38]: configuring uniqueness plugin > [10/38]: configuring uuid plugin > [11/38]: configuring modrdn plugin > [12/38]: configuring DNS plugin > [13/38]: enabling entryUSN plugin > [14/38]: configuring lockout plugin > [15/38]: creating indices > [16/38]: enabling referential integrity plugin > [17/38]: configuring certmap.conf > [18/38]: configure autobind for root > [19/38]: configure new location for managed entries > [20/38]: configure dirsrv ccache > [21/38]: enable SASL mapping fallback > [22/38]: restarting directory server > [23/38]: adding default layout > [24/38]: adding delegation layout > [25/38]: creating container for managed entries > [26/38]: configuring user private groups > [27/38]: configuring netgroups from hostgroups > [28/38]: creating default Sudo bind user > [29/38]: creating default Auto Member layout > [30/38]: adding range check plugin > [31/38]: creating default HBAC rule allow_all > [32/38]: initializing group membership > [33/38]: adding master entry > [34/38]: configuring Posix uid/gid generation > [35/38]: adding replication acis > [36/38]: enabling compatibility plugin > [37/38]: tuning directory server > [38/38]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 > seconds > [1/27]: creating certificate server user > [2/27]: configuring certificate server instance > [3/27]: stopping certificate server instance to update CS.cfg > [4/27]: backing up CS.cfg > [5/27]: disabling nonces > [6/27]: set up CRL publishing > [7/27]: enable PKIX certificate path discovery and validation > [8/27]: starting certificate server instance > [9/27]: creating RA agent certificate database > [10/27]: importing CA chain to RA certificate database > [error] RuntimeError: Unable to retrieve CA chain: mismatched tag: line > 29, column 2 > Unable to retrieve CA chain: mismatched tag: line 29, column 2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Sat Nov 22 21:14:52 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Sat, 22 Nov 2014 13:14:52 -0800 Subject: [Freeipa-users] FreeIPA4 OTP vs PAM In-Reply-To: References: <20140815080736.GO3684@hendrix.redhat.com> Message-ID: Reviving this as I am still stuck with CentOS 6. CentOS 6.6 now has sssd 1.11 - yet I still cannot get the OTP to work under PAM: I created a test user and added an otp. User works fine without the OTP, however I keep getting this when trying to test with OTP via pamtester: pamtester: pam_sss(login:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=michael pamtester: pam_sss(login:auth): received for user michael: 17 (Failure setting user credentials) Is there a way to get more information as to what is going on? Is my expectation that I would provide otp in a form of "password123456" correct (assuming my password is "password" and otp token is "123456")? On Fri, Aug 15, 2014 at 2:29 AM, Michael Lasevich wrote: > Thanks, glad I asked before wasting time. > > > On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek wrote: > >> On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: >> > I did not dive into this yet, but before I waste too much time I wanted >> to >> > ask if centos 6.5 default ipa client expected to work with 2FA or not. >> >> No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of >> fixes that landed during the 1.11 development such as: >> https://fedorahosted.org/sssd/ticket/2186 >> or: >> https://fedorahosted.org/sssd/ticket/2271 >> plus some other commits I see in git log which don't reference any ticket. >> >> I'd suggest to test using a centos 7.0 client. >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosmefc at gmail.com Sat Nov 22 21:51:45 2014 From: cosmefc at gmail.com (=?UTF-8?B?Q29zbWUgQ29ycsOqYQ==?=) Date: Sat, 22 Nov 2014 16:51:45 -0500 Subject: [Freeipa-users] Freeipa and EDUROAM Message-ID: <54710571.8000605@gmail.com> Hi, I am an "EDUROAM administrator". We use openldap, but i would like to migrate to freeipa. Has anyone done this before? Any help would be greatly appreciated. -- Cosme Faria Corr?a -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Sat Nov 22 22:05:19 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Sat, 22 Nov 2014 14:05:19 -0800 Subject: [Freeipa-users] FreeIPA4 OTP vs PAM In-Reply-To: References: <20140815080736.GO3684@hendrix.redhat.com> Message-ID: 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.com at 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.com at 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.com at MY.DOMAIN.COM -> krbtgt/ MY.DOMAIN.COM at 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 michael at 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.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM at 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.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM at 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.com at MY.DOMAIN.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM \@MY.DOMAIN.COM at 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.com at MY.DOMAIN.COM -> krbtgt/ MY.DOMAIN.COM at 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.com at MY.DOMAIN.COM -> krbtgt/ MY.DOMAIN.COM at 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]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366425: Armor ccache sesion key: aes256-cts/9082 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366476: Creating authenticator for host/ipaclient.my.domain.com at MY.DOMAIN.COM -> krbtgt/ MY.DOMAIN.COM at MY.DOMAIN.COM, seqnum 0, subkey aes256-cts/F5B0, session key aes256-cts/9082 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366562: FAST armor key: aes256-cts/0D88 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366605: Encoding request body and padata into FAST request (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366675: Sending request (1089 bytes) to MY.DOMAIN.COM (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366752: 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.370122: 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.370193: Response was from master KDC (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370232: 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.370262: Decoding FAST response (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370333: Processing preauth types: 136, 141, 133, 137 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370364: Received cookie: MIT (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370404: Produced preauth for next request: 133 (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [get_and_save_tgt] (0x0020): 981: [-1765328174][Generic preauthentication failure] (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [map_krb5_error] (0x0020): 1043: [-1765328174][Generic preauthentication failure] ================= On Sat, Nov 22, 2014 at 1:14 PM, Michael Lasevich wrote: > Reviving this as I am still stuck with CentOS 6. > > CentOS 6.6 now has sssd 1.11 - yet I still cannot get the OTP to work > under PAM: > > I created a test user and added an otp. User works fine without the OTP, > however I keep getting this when trying to test with OTP via pamtester: > > pamtester: pam_sss(login:auth): authentication failure; logname= uid=0 > euid=0 tty= ruser= rhost= user=michael > pamtester: pam_sss(login:auth): received for user michael: 17 (Failure > setting user credentials) > > Is there a way to get more information as to what is going on? > > Is my expectation that I would provide otp in a form of "password123456" > correct (assuming my password is "password" and otp token is "123456")? > > > > On Fri, Aug 15, 2014 at 2:29 AM, Michael Lasevich > wrote: > >> Thanks, glad I asked before wasting time. >> >> >> On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek wrote: >> >>> On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: >>> > I did not dive into this yet, but before I waste too much time I >>> wanted to >>> > ask if centos 6.5 default ipa client expected to work with 2FA or not. >>> >>> No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of >>> fixes that landed during the 1.11 development such as: >>> https://fedorahosted.org/sssd/ticket/2186 >>> or: >>> https://fedorahosted.org/sssd/ticket/2271 >>> plus some other commits I see in git log which don't reference any >>> ticket. >>> >>> I'd suggest to test using a centos 7.0 client. >>> >>> -- >>> 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 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Sat Nov 22 22:13:42 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Sun, 23 Nov 2014 09:13:42 +1100 Subject: [Freeipa-users] Freeipa and EDUROAM In-Reply-To: <54710571.8000605@gmail.com> References: <54710571.8000605@gmail.com> Message-ID: On Sun, Nov 23, 2014 at 8:51 AM, Cosme Corr?a wrote: > Hi, > > I am an "EDUROAM administrator". > We use openldap, but i would like to migrate to freeipa. > > Has anyone done this before? > > Any help would be greatly appreciated. > can you help define what eduroam is? are you referring to the federated wireless network infrastructures being deployed by universities around the world? > > > -- > Cosme Faria Corr?a > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Sat Nov 22 22:36:41 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Sun, 23 Nov 2014 09:36:41 +1100 Subject: [Freeipa-users] curious about monkeysphere Message-ID: ??Im curious about monkeysphere http://web.monkeysphere.info/ and how it might compare, integrate, enhance freeipa ..... any thoughts, or ideas, or is what it does basically already covered via freeipa? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Nov 24 08:51:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Nov 2014 09:51:23 +0100 Subject: [Freeipa-users] Free ipa Configurations In-Reply-To: <2001848902.1902142.1416300854811.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> References: <54630D8F.2020002@redhat.com> <2001848902.1902142.1416300854811.JavaMail.yahoo@jws106136.mail.bf1.yahoo.com> Message-ID: <5472F18B.3060205@redhat.com> On 18.11.2014 09:54, Rolf Nufable wrote: > Hello all I have a question regarding the log in in IPA > well I didn't expect this to happen since last week all installation went smoothly and the adding of the clients as well but now I have another problem. > My first problem was ntp/ntpdate wasn't cooperating well and it won't update my fedora 20 time correctly every reboot, so I get the wrong time and manually issue the ntpdate just to get the correct time... ( well this problem is small ) > So what I did was just configured/updated the timezone of the Freeipa Server. then I tried rebooting it 3 times in a row just to make sure it won't change time. and it was successful. ( I did this last friday ) > yesterday I checked the time of the free ipa server. and it was way off.. Now my problem is that if I edited the time or restarted ntpd / ntpdate I cannot log-in to the web UI of freeipa although I'm using the admin account and the right credentials as well , It asks me to configure the browser credentials ( the one going to about:config ) but I still cannot log in, And I don't really know why .. But if I didn't I can Log in smoothly.. > any Ideas on whats causing this error? > TIA :) Maybe some timestamps in Kerberos tickets you have 'cached' locally are wrong. I would try to check timestampt in "klist" output or try to kdestroy & kinit again. Petr^2 Spacek > > On Tuesday, November 11, 2014 11:34 PM, Martin Kosek wrote: > > > On 11/12/2014 04:09 AM, Rolf Nufable wrote: >> I have another question, well I've achieved the state where I can't log in to my admin account in the server side, it happens because I'm changing the time of the server machine. >> >> but the time is really wrong. and I disabled NTP and the server has no access to the internet. >> >> these are my network configurations. >> >> peerdns = no >> ipaddr = 192.168.1.1 >> netmask = 255.255.255.0 >> dns1 = 192.168.1.1 >> onboot = yes >> >> as you can see I've made the server also the dns1, (is this correct though ? i really don't know ) >> >> feel free to correct my network config >> >> And another problem is that I need to sync my freeipa server time to the right time zone? if thats the case then I do need internet connection for my Freeipa server , so that it could access ntp servers right? ( or am I wrong? ) > > Yes, internet connection helps. Theoretically you could just set up the time > manually on your FreeIPA server and then let your clients synchronize their > time with it as NTP is running there, but that may be cumbersome. > >> >> still this is a great breakthrough for my work >> >> Now what to do? > > FreeIPA server and the KDC do not care about the time zone, it works with UTC > time anyway, AFAIK. You just simply need to have the time synchronized on all > your servers and clients or Kerberos protocol will not work. > >> ps. Martin attached is the krb5kdc.log after I changed the time of the server. Httpd error log didnt changed at all after I tried to access the web UI and tried to log in.. > > I saw no error there... > >> >> >> TIA >> >> >> >> On Tuesday, November 11, 2014 7:10 PM, Petr Vobornik wrote: >> >> >> >> On 11.11.2014 11:11, Jakub Hrozek wrote: >>> On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote: >>>> well I'm trying to setup sudo in my client machine, also I want to access the server web browser In the client machine ( is it possible though ? ) >>>> >>>> well I'm having this error in the client side when using the command su - ( user ) >>>> >>>> su - user at example.com >>>> >>>> su : user at example.com does not exist. >>> >>> Are you sure ipa-client-install did run successfully on that machine? >>> >>> Can you unenroll and enroll the client back so that we start from an >>> sssd.conf that is created by the tooling? >>> >>> As Martin said, you don't need those sudo-related config options with >>> recent SSSD releases, they wouldn't work in the sudo section anyway. >> >> Does: >> >> $ id user at example.com >> >> return you the user info? >> >> if not and ipa-client-install was run successfully before, check >> nsswitch.conf if it has sssd configured (sss next to various providers). >> >> if not run: >> $ authconfig --enablesssd --update >> >> if it doesn't help, try to run: >> $ authconfig --disablesssd --update >> $ authconfig --enablesssd --update >> >> if it helps, please tell me. I'm curious if you suffer from one issue I >> experienced. >> >> >> >>> >>>> >>>> >>>> >>>> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek wrote: >>>> >>>> >>>> >>>> It is still really hard to give advise as I do not know what's actually wrong. >>>> So are you trying to set up a sudo on your client or are you trying to log in >>>> with your client browser to FreeIPA server? These are 2 orthogonal actions. >>>> >>>> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I >>>> cannot help you without described procedure you are trying to do, logs and >>>> exact error messages. >>>> >>>> Martin >>>> >>>> >>>> On 11/11/2014 09:32 AM, Rolf Nufable wrote: >>>>> never mind the problem on the server side, somehow it got fixed , I really don't know how though >>>>> >>>>> so in the client side , It is successful when installing free ipa client and the >>>> server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 (although somewhere I've read that version incompatibility would not be an issue since if either one is of a lower version, the only features that would be used is the one that the lower version can do ) >>>>> >>>>> So I really don't know why Can't I connect to the ipa server. >>>>> >>>>> Iptables works fine. >>>>> /etc/resolv.conf is file as well >>>>> >>>>> sssd/sssd.conf ( added these lines ) >>>>> [sudo] >>>>> sudo_provider = ldap >>>>> ldap_uri = ldap://myipaserver.example.com >>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>> ldap_sasl_mech = GSSAPI >>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>> ldap_sasl_realm = EXAMPLE.COM >>>>> krb_server = myipaserver.example.com >>>>> >>>>> >>>>> and /etc/nsswitch.conf >>>>> (added this line ) >>>>> >>>>> sudoers : files sss ldap >>>>> >>>>> is there something missing ? >>>>> >>>>> >>>>> >>>>> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable wrote: >>>>> >>>>> >>>>> >>>>> oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris " they have the same domain as of the server side I've configured it as well as in the client side because recent guides for deploying IPA says that you must go to about:config either >>>> you are on the server or client side, or at least thats what I remember. >>>>> >>>>> Wait a sec I'm trying to achieve the state again where the server side wont let me log in using the admin credentials , just so i could show you the logs >>>>> >>>>> >>>>> >>>>> >>>>> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek wrote: >>>>> >>>>> >>>>> >>>>> On 11/11/2014 08:07 AM, Rolf Nufable wrote: >>>>>> well I dont know how or what command to use to display the logs, could you teach me how? >>>>> >>>>> There should be HOWTO articles on how to do that. Jakub may have better >>>>> sources, but I see for >>>> example: >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html >>>>> >>>>>> , but yes the network.negotiate-auth.trusted-uris has the same domain name which is example.com this is on the server side only >>>>> >>>>> network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine. >>>>> >>>>>> while on the client side, even >>>>> though the network.negotiate-auth.trusted-uris is configured correctly, the web UI can't be accessed so its a really weird scenario. but the registration of the ipa client to the server says its successful. >>>>> >>>>> FreeIPA 4.0+ Web UI should allow you to login at least with your user+password, >>>>> if SSO login fails. Does at least this part work? Because if not, there is some >>>>> error on the server side. It would be interesting to check if there are no >>>>> errors on the server in following logs: >>>>> - /var/log/httpd/error_log >>>>> - /var/log/krb5kdc.log >>>>> >>>>> >>>>> >>>>>> >>>>>> TIA >>>>>> >>>>>> >>>>>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 11/11/2014 06:37 AM, Rolf Nufable >>>> wrote: >>>>>>> or could you guys direct me or guide me on how to deploy this ipa server? I've been successful deploying ipa version 3.3.5 before but this 4.0 and above series is really giving me a headache >>>>>> >>>>>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to >>>>>> deploy, on the >>>>> contrary, it should be much cooler than 3.3. >>>>>> >>>>>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> well I'll try them now, my sssd config only consists of these lines added to the sudo area >>>>>>> >>>>>>> sudo_provider = ldap >>>>>>> ldap_uri = ldap://myipaserver.example.com >>>>>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >>>>>>> ldap_sasl_mech = >>>>> GSSAPI >>>>>>> ldap_sasl_authid = host/myipaserver.example.com >>>>>>> ldap_sasl_realm = EXAMPLE.COM >>>>>>> krb_server = myipaserver.example.com >>>>>> >>>>>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo >>>>>> provider. Actually, FreeIPA 4.0+ clients do that for you. >>>>>> >>>>>> More info here: >>>>>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>>>> https://fedorahosted.org/freeipa/ticket/3358 >>>>>> >>>>>>> plus another question why is it that when I invoke the kinit admin command for the kerberos I couldnt access the web UI and keeps asking me to configure my web browser ( firefox) though I've already configured it many times.. >>>>>> >>>>>> Are you sure that network.negotiate-auth.trusted-uris in about:config >>>>>> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but >>>>>> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what >>>>>> is the setting of network.negotiate-auth.trusted-uris? >>>>>> >>>>>> In any case, it is still hard to >>>>> advise as I still did not see any related >>>>>> logs, error messages or actual real errors preventing you from enrolling FreeIPA. >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> TIA >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote: >>>>>>> >>>>>>>> On 11/10/2014 02:05 AM, Rolf >>>>>>> Nufable wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> I have tons of questions on why free ipa wont't work on my network , I've been using fedora 20 as the os for the server and client free ipa . >>>>>>>>> >>>>>>>>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the client side using 2 VM's at first it was okay, got it connected and used ldap to pass sudo for the client side, but when I finally deployed it >>>>> in our real network consisting of an esxi server and one work station having the same versions of free ipa for server and client, the error that I'm getting is that " the user does not exist " when I invoked the " su - ( user ) " command, so My question >>>> is how can I solve this problem?? I've been at it for 3 weeks now .. >>>>>>>> >>>>>>>> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I >>>>>>>> assume this is a problem in SSSD client part, if the user cannot be found. >>>>>>>> CCing Lukas and Jakub to advise. >>>>>>> >>>>>>> Sorry, I skipped this thread b/c the subject didn't look like it was >>>>>>> SSSD-related. >>>>>>> >>>>>>> I think we need to examine SSSD logs... From pspacek at redhat.com Mon Nov 24 08:56:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Nov 2014 09:56:24 +0100 Subject: [Freeipa-users] Freeipa Forwarders In-Reply-To: <740323710.3185413.1416467882151.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> References: <740323710.3185413.1416467882151.JavaMail.yahoo@jws10601.mail.bf1.yahoo.com> Message-ID: <5472F2B8.8040405@redhat.com> On 20.11.2014 08:18, Rolf Nufable wrote: > I have a quick question Do I need to configure the forwarders of freeipa-server 4.1.1 when doing the freeipa-install-server? This is *necessary* only if you have some internal DNS zones which are not resolvable using public DNS infrastructure. In all other cases it is purely optional cache optimization. > I forgot the reason why I don't need to because my email suddenly deleted that message from Martin, and now I can't remember why or how not to include a forwarder, and how to add a forwarder manually.. > > **********************UPDATE ************************************************ > I've installed freeipa 4.1.1 --setup-dns --no-forwarders so far the installation went well .. but I need to configure freeipa server as a forwarder right? > so I used te web UI and added the freeipaserver ip as a forwarder, then I rebooted the freeipa server. > after the reboot I couldn't access the web browser. > Any idea on how can I fix this?? This is probably unrelated to forwarders. Which error message are you receiving, exactly? -- Petr^2 Spacek From desantis at mail.usf.edu Mon Nov 24 12:08:26 2014 From: desantis at mail.usf.edu (John Desantis) Date: Mon, 24 Nov 2014 07:08:26 -0500 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: <54490400.50803@redhat.com> References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> <54480A43.1020700@redhat.com> <54490400.50803@redhat.com> Message-ID: Hello again, I was just wondering if there was an update on this thread? Since it is just one machine having an issue, do you (Rob and Rich) think a re-initialization from the master on the affected host would clear the clog? I have left it alone since Mark was brought into the discussion. Thank you! John DeSantis 2014-10-23 9:34 GMT-04:00 Rich Megginson : > On 10/23/2014 07:01 AM, John Desantis wrote: >> >> Rob and Rich, >> >>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>> cleaning. >>> >>> I remember having previously tried this task, but it had failed on >>> older RUV's which were not even active (the KDC was under some strain >>> so ipa queries were timing out). However, I ran it again and have >>> been able to delete all but 1 (it's still running) RUV referencing the >>> previous replica. >>> >>> I'll report back once the tasks finishes or fails. >> >> The last RUV is "stuck" on another replica. It fails with the following >> error: >> >> [23/Oct/2014:08:55:09 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Initiating CleanAllRUV Task... >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Retrieving maxcsn... >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Found maxcsn (5447f861000000180000) >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Cleaning rid (24)... >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting to process all the updates from the deleted replica... >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting for all the replicas to be online... >> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting for all the replicas to receive all the deleted replica >> updates... >> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Replica maxcsn (5447f56b000200180000) is not caught up with deleted >> replica's maxcsn(5447f861000000180000) >> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" >> (iparepbackup:389)) >> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Not all replicas caught up, retrying in 10 seconds >> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Replica maxcsn (5447f56b000200180000) is not caught up with deleted >> replica's maxcsn(5447f861000000180000) >> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" >> (iparepbackup:389)) >> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >> Not all replicas caught up, retrying in 20 seconds >> >> I then abort the task since the retrying went up to 14400 seconds. > > > Mark, do you know what is going on here? > > >> >> Would this be a simple re-initialization from the master on the host >> "iparepbackup"? >> >> Thanks, >> John DeSantis >> >> 2014-10-22 16:03 GMT-04:00 John Desantis : >>> >>> Rob and Rich, >>> >>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>> cleaning. >>> >>> I remember having previously tried this task, but it had failed on >>> older RUV's which were not even active (the KDC was under some strain >>> so ipa queries were timing out). However, I ran it again and have >>> been able to delete all but 1 (it's still running) RUV referencing the >>> previous replica. >>> >>> I'll report back once the tasks finishes or fails. >>> >>> Thanks, >>> John DeSantis >>> >>> >>> 2014-10-22 15:49 GMT-04:00 Rob Crittenden : >>>> >>>> Rich Megginson wrote: >>>>> >>>>> On 10/22/2014 12:55 PM, John Desantis wrote: >>>>>> >>>>>> Richard, >>>>>> >>>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>>> were not >>>>>>> cleaned. You may have to use cleanallruv manually. >>>>>>> >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>>> >>>>>>> >>>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>>> >>>>>> I'll try that, thanks for the guidance. >>>>>> >>>>>>> What is the real problem you have? Did replication stop working? Are >>>>>>> you >>>>>>> getting error messages? >>>>>> >>>>>> I cannot get the host to be a replica. Each time I run >>>>>> `ipa-replica-install >>>>>> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >>>>>> had assumed it was due to the fact that the host was already a >>>>>> replica, but had to be taken offline due to a hard disk failing. The >>>>>> machine was re-provisioned after the new hard drive was installed. >>>>> >>>>> Ok. I don't know if we have a documented procedure for that case. I >>>>> assumed that if you first ran ipa-replica-manage del, then >>>>> ipa-replica-prepare, then ipa-replica-install, that would take care of >>>>> that. >>>> >>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>> cleaning. >>>> >>>>>> When I enabled extra debugging during the installation process, the >>>>>> initial error was that the dirsrv instance couldn't be started. I >>>>>> checked into this and found that there were missing files in >>>>>> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >>>>>> after copying some schema files from another replica. The install did >>>>>> move forward but then failed with Apache and its IPA configuration. >>>>>> >>>>>> I performed several uninstalls and re-installs, and at one point I got >>>>>> error code 3 from ipa-replica-install, which is why I was thinking >>>>>> that the old RUV's and tombstones were to blame. >>>>> >>>>> It could be. I'm really not sure what the problem is at this point. >>>> >>>> I think we'd need to see ipareplica-install.log to know for sure. It >>>> could be the sort of thing where it fails early but doesn't kill the >>>> install, so the last error is a red herring. >>>> >>>> rob >>>> >>>>>> Thanks, >>>>>> John DeSantis >>>>>> >>>>>> >>>>>> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>>>>>> >>>>>>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>>>>>> >>>>>>>> Richard, >>>>>>>> >>>>>>>> You helped me before in #freeipa, so I appreciate the assistance >>>>>>>> again. >>>>>>>> >>>>>>>>> What version of 389 are you using? >>>>>>>>> rpm -q 389-ds-base >>>>>>>> >>>>>>>> 389-ds-base-1.2.11.15-34.el6_5 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> John DeSantis >>>>>>>> >>>>>>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>>>>>> >>>>>>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>>>>>> >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>>>>>> for a >>>>>>>>>> great product! >>>>>>>>>> >>>>>>>>>> Now, to the point! >>>>>>>>>> >>>>>>>>>> We're trying to re-provision a previous replica using the standard >>>>>>>>>> documentation via the Red Hat site: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, we're running into errors during the import process. The >>>>>>>>>> errors are varied and fail at random steps; there was an issue >>>>>>>>>> with >>>>>>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>>>>>> separate node to become a replica. >>>>>>>>>> >>>>>>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>>>>>> and >>>>>>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>>>>>> records and verified that the host enrollment was not present. I >>>>>>>>>> did >>>>>>>>>> not use the "--force" and "--cleanup" options. >>>>>>>>> >>>>>>>>> What version of 389 are you using? >>>>>>>>> rpm -q 389-ds-base >>>>>>> >>>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>>> were not >>>>>>> cleaned. You may have to use cleanallruv manually. >>>>>>> >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>>> >>>>>>> >>>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>>>> >>>>>>>>>> When I check RUV's against the host in question, there are >>>>>>>>>> several. I >>>>>>>>>> also queried the tombstones against the host and found two entries >>>>>>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>>>>>> sanitized output below: >>>>>>>>>> >>>>>>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>>>>>> Enter LDAP Password: >>>>>>>>>> dn: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>>>>>> >>>>>>>>>> objectClass: top >>>>>>>>>> objectClass: nsTombstone >>>>>>>>>> objectClass: extensibleobject >>>>>>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>>>>>> nsds50ruv: {replica 22 >>>>>>>>>> ldap://separatenode.our.personal.domain:389} >>>>>>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>>>>>> nsds50ruv: {replica 21 >>>>>>>>>> ldap://iparepbackup.our.personal.domain:389} >>>>>>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>>>>>> nsds50ruv: {replica 19 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> 510d56c9000100130000 >>>>>>>>>> 510d82 be000200130000 >>>>>>>>>> nsds50ruv: {replica 18 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 17 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 16 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 15 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 14 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 13 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 12 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> nsds50ruv: {replica 23 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>> 54187702000200170000 >>>>>>>>>> 541878 9a000000170000 >>>>>>>>>> dc: our >>>>>>>>>> nsruvReplicaLastModified: {replica 4 >>>>>>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>>>>>> nsruvReplicaLastModified: {replica 22 >>>>>>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>>>>>> nsruvReplicaLastModified: {replica 21 >>>>>>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 19 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 18 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 17 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 16 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 15 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 14 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 13 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 12 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> nsruvReplicaLastModified: {replica 23 >>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>> >>>>>>>>>> dn: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>>> >>>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>>> objectClass: top >>>>>>>>>> objectClass: nsContainer >>>>>>>>>> objectClass: nsTombstone >>>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>>> >>>>>>>>>> dn: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>>> >>>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>>> objectClass: top >>>>>>>>>> objectClass: nsContainer >>>>>>>>>> objectClass: nsTombstone >>>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>>> >>>>>>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>>>>>> two >>>>>>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>>>>>> "host-in-question". >>>>>>>>>> >>>>>>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>>>>>> replica? >>>>>>> >>>>>>> No, you cannot delete tombstones manually. They will be cleaned up >>>>>>> at some >>>>>>> point by the dirsrv tombstone reap thread, and they should not be >>>>>>> interfering with anything. >>>>>>> >>>>>>> What is the real problem you have? Did replication stop working? Are >>>>>>> you >>>>>>> getting error messages? >>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> John DeSantis >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>> >>>>>>> -- >>>>>>> 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 > > From mariajose1982 at gmail.com Mon Nov 24 12:56:38 2014 From: mariajose1982 at gmail.com (=?UTF-8?Q?Maria_Jose_Ya=C3=B1ez_Dacosta?=) Date: Mon, 24 Nov 2014 10:56:38 -0200 Subject: [Freeipa-users] Setting up a Kerberized IMAP Server. Message-ID: Hi!, I'm installing a Zimbra server to authenticate using SSO against FreeIPA. When when trying to access I'm getting an error which makes me think that probably I forget set something else in FreeIPA configuration. Because I'm a newbie with using FreeIPA. And when I configured SSO with existing Kerberos installation it worked. So surely the mistake is mine to configure something on FreeIPA. I tell some details about it but if you need more information y can share it with all you. As a client to access via GSSAPI use Thunderbird. The error I get: "The Kerberos/GSSAPI ticket was not accepted by the IMAP server usuipa at fi.example.com. Please check that you are logged in to the Kerberos/GSSAPI realm". Steps to Reproduce in FreeIPA: 1) I add the entry to the imap service by Identity Management. In Services HBAC add imap/fi.example.com at FI.EXAMPLE.COM. By clicking on it. I get the following information about status: - Key current Kerberos Service provided - Service Certificate: Certificate not valid 2) I got the keytab which is then used in the installation of Zimbra as follows: ipa-getkeytab freeipafi.example.com -p -s imap / zimbrafreeipa.fi.example.com -k /tmp/keytab/ticket.keytab Thanks for any help or clarification. Greetings!. -- Maria Jos? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Nov 24 13:32:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Nov 2014 14:32:24 +0100 Subject: [Freeipa-users] Setting up a Kerberized IMAP Server. In-Reply-To: References: Message-ID: <54733368.7090909@redhat.com> On 24.11.2014 13:56, Maria Jose Ya?ez Dacosta wrote: > Hi!, > > I'm installing a Zimbra server to authenticate using SSO against FreeIPA. > When when trying to access I'm getting an error which makes me think that > probably I forget set something else in FreeIPA configuration. > > Because I'm a newbie with using FreeIPA. > And when I configured SSO with existing Kerberos installation it worked. > So surely the mistake is mine to configure something on FreeIPA. > > I tell some details about it but if you need more information y can share > it with all you. > > As a client to access via GSSAPI use Thunderbird. > > The error I get: > > "The Kerberos/GSSAPI ticket was not accepted by the IMAP server > usuipa at fi.example.com. > Please check that you are logged in to the Kerberos/GSSAPI realm". > > Steps to Reproduce in FreeIPA: > > 1) I add the entry to the imap service by Identity Management. > In Services HBAC add imap/fi.example.com at FI.EXAMPLE.COM. > > By clicking on it. > I get the following information about status: > - Key current Kerberos Service provided > - Service Certificate: Certificate not valid > > 2) I got the keytab which is then used in the installation of Zimbra as > follows: > > ipa-getkeytab freeipafi.example.com -p -s imap / > zimbrafreeipa.fi.example.com -k /tmp/keytab/ticket.keytab > > Thanks for any help or clarification. > Greetings!. For the beginning, try to run this on the *client* machine: $ kvno imap/fi.example.com at FI.EXAMPLE.COM If it works then Kerberos principal itself and client configuration should be okay and it is necessary to look at server configuration. If it doesn't work you may try to run it as: $ KRB5_TRACE=/dev/stdout kvno imap/fi.example.com at FI.EXAMPLE.COM or alternatively $ KRB5_TRACE=/dev/stdout thunderbird and check debug messages. Usual mistakes: - wrong file permissions on keytab file used by server - wrong SELinux label on the keytab file - wrong DNS configuration which prevents client from finding server or KDC (this possibility should be eliminated by kvno command above) Have a nice day! -- Petr^2 Spacek From rcritten at redhat.com Mon Nov 24 16:01:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Nov 2014 11:01:55 -0500 Subject: [Freeipa-users] Attempting to re-provision previous replica In-Reply-To: References: <5447D6CE.1020305@redhat.com> <5447E090.9000901@redhat.com> <54480312.1010409@redhat.com> <54480A43.1020700@redhat.com> <54490400.50803@redhat.com> Message-ID: <54735673.3030601@redhat.com> John Desantis wrote: > Hello again, > > I was just wondering if there was an update on this thread? > > Since it is just one machine having an issue, do you (Rob and Rich) > think a re-initialization from the master on the affected host would > clear the clog? I have left it alone since Mark was brought into the > discussion. A re-init won't help because the RUVs are stored outside of the replicated data. rob > > Thank you! > John DeSantis > > 2014-10-23 9:34 GMT-04:00 Rich Megginson : >> On 10/23/2014 07:01 AM, John Desantis wrote: >>> >>> Rob and Rich, >>> >>>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>>> cleaning. >>>> >>>> I remember having previously tried this task, but it had failed on >>>> older RUV's which were not even active (the KDC was under some strain >>>> so ipa queries were timing out). However, I ran it again and have >>>> been able to delete all but 1 (it's still running) RUV referencing the >>>> previous replica. >>>> >>>> I'll report back once the tasks finishes or fails. >>> >>> The last RUV is "stuck" on another replica. It fails with the following >>> error: >>> >>> [23/Oct/2014:08:55:09 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Initiating CleanAllRUV Task... >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Retrieving maxcsn... >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Found maxcsn (5447f861000000180000) >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Cleaning rid (24)... >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Waiting to process all the updates from the deleted replica... >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Waiting for all the replicas to be online... >>> [23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Waiting for all the replicas to receive all the deleted replica >>> updates... >>> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Replica maxcsn (5447f56b000200180000) is not caught up with deleted >>> replica's maxcsn(5447f861000000180000) >>> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" >>> (iparepbackup:389)) >>> [23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Not all replicas caught up, retrying in 10 seconds >>> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Replica maxcsn (5447f56b000200180000) is not caught up with deleted >>> replica's maxcsn(5447f861000000180000) >>> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Replica not caught up (agmt="cn=meToiparepbackup.our.personal.domain" >>> (iparepbackup:389)) >>> [23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task: >>> Not all replicas caught up, retrying in 20 seconds >>> >>> I then abort the task since the retrying went up to 14400 seconds. >> >> >> Mark, do you know what is going on here? >> >> >>> >>> Would this be a simple re-initialization from the master on the host >>> "iparepbackup"? >>> >>> Thanks, >>> John DeSantis >>> >>> 2014-10-22 16:03 GMT-04:00 John Desantis : >>>> >>>> Rob and Rich, >>>> >>>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>>> cleaning. >>>> >>>> I remember having previously tried this task, but it had failed on >>>> older RUV's which were not even active (the KDC was under some strain >>>> so ipa queries were timing out). However, I ran it again and have >>>> been able to delete all but 1 (it's still running) RUV referencing the >>>> previous replica. >>>> >>>> I'll report back once the tasks finishes or fails. >>>> >>>> Thanks, >>>> John DeSantis >>>> >>>> >>>> 2014-10-22 15:49 GMT-04:00 Rob Crittenden : >>>>> >>>>> Rich Megginson wrote: >>>>>> >>>>>> On 10/22/2014 12:55 PM, John Desantis wrote: >>>>>>> >>>>>>> Richard, >>>>>>> >>>>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>>>> were not >>>>>>>> cleaned. You may have to use cleanallruv manually. >>>>>>>> >>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>>>> >>>>>>>> >>>>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>>>> >>>>>>> I'll try that, thanks for the guidance. >>>>>>> >>>>>>>> What is the real problem you have? Did replication stop working? Are >>>>>>>> you >>>>>>>> getting error messages? >>>>>>> >>>>>>> I cannot get the host to be a replica. Each time I run >>>>>>> `ipa-replica-install >>>>>>> replica-info-host-in-question.our.personal.domain.gpg' it fails. I >>>>>>> had assumed it was due to the fact that the host was already a >>>>>>> replica, but had to be taken offline due to a hard disk failing. The >>>>>>> machine was re-provisioned after the new hard drive was installed. >>>>>> >>>>>> Ok. I don't know if we have a documented procedure for that case. I >>>>>> assumed that if you first ran ipa-replica-manage del, then >>>>>> ipa-replica-prepare, then ipa-replica-install, that would take care of >>>>>> that. >>>>> >>>>> ipa-replica-manage del should have cleaned things up. You can clear out >>>>> old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use >>>>> list-ruv to get the id# to clean and clean-ruv to do the actual >>>>> cleaning. >>>>> >>>>>>> When I enabled extra debugging during the installation process, the >>>>>>> initial error was that the dirsrv instance couldn't be started. I >>>>>>> checked into this and found that there were missing files in >>>>>>> /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv >>>>>>> after copying some schema files from another replica. The install did >>>>>>> move forward but then failed with Apache and its IPA configuration. >>>>>>> >>>>>>> I performed several uninstalls and re-installs, and at one point I got >>>>>>> error code 3 from ipa-replica-install, which is why I was thinking >>>>>>> that the old RUV's and tombstones were to blame. >>>>>> >>>>>> It could be. I'm really not sure what the problem is at this point. >>>>> >>>>> I think we'd need to see ipareplica-install.log to know for sure. It >>>>> could be the sort of thing where it fails early but doesn't kill the >>>>> install, so the last error is a red herring. >>>>> >>>>> rob >>>>> >>>>>>> Thanks, >>>>>>> John DeSantis >>>>>>> >>>>>>> >>>>>>> 2014-10-22 12:51 GMT-04:00 Rich Megginson : >>>>>>>> >>>>>>>> On 10/22/2014 10:31 AM, John Desantis wrote: >>>>>>>>> >>>>>>>>> Richard, >>>>>>>>> >>>>>>>>> You helped me before in #freeipa, so I appreciate the assistance >>>>>>>>> again. >>>>>>>>> >>>>>>>>>> What version of 389 are you using? >>>>>>>>>> rpm -q 389-ds-base >>>>>>>>> >>>>>>>>> 389-ds-base-1.2.11.15-34.el6_5 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> John DeSantis >>>>>>>>> >>>>>>>>> 2014-10-22 12:09 GMT-04:00 Rich Megginson : >>>>>>>>>> >>>>>>>>>> On 10/22/2014 09:42 AM, John Desantis wrote: >>>>>>>>>>> >>>>>>>>>>> Hello all, >>>>>>>>>>> >>>>>>>>>>> First and foremost, a big "thank you!" to the FreeIPA developers >>>>>>>>>>> for a >>>>>>>>>>> great product! >>>>>>>>>>> >>>>>>>>>>> Now, to the point! >>>>>>>>>>> >>>>>>>>>>> We're trying to re-provision a previous replica using the standard >>>>>>>>>>> documentation via the Red Hat site: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, we're running into errors during the import process. The >>>>>>>>>>> errors are varied and fail at random steps; there was an issue >>>>>>>>>>> with >>>>>>>>>>> NTP or HTTP or LDAP, etc. This did not happen when we promoted a >>>>>>>>>>> separate node to become a replica. >>>>>>>>>>> >>>>>>>>>>> We had previously removed the replica via `ipa-replica-manage del` >>>>>>>>>>> and >>>>>>>>>>> ensured that no trace of it being a replica existed: removed DNS >>>>>>>>>>> records and verified that the host enrollment was not present. I >>>>>>>>>>> did >>>>>>>>>>> not use the "--force" and "--cleanup" options. >>>>>>>>>> >>>>>>>>>> What version of 389 are you using? >>>>>>>>>> rpm -q 389-ds-base >>>>>>>> >>>>>>>> You should remove the unused ruv elements. I'm not sure why they >>>>>>>> were not >>>>>>>> cleaned. You may have to use cleanallruv manually. >>>>>>>> >>>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv >>>>>>>> >>>>>>>> >>>>>>>> note - use the cleanallruv procedure, not cleanruv. >>>>>>>> >>>>>>>>>>> When I check RUV's against the host in question, there are >>>>>>>>>>> several. I >>>>>>>>>>> also queried the tombstones against the host and found two entries >>>>>>>>>>> which have valid hex time stamps; coincidentally, out of the 9 >>>>>>>>>>> tombstone entries, 2 have "nsds50ruv" time stamps. I'll paste >>>>>>>>>>> sanitized output below: >>>>>>>>>>> >>>>>>>>>>> # ldapsaerch -x -W -LLL -D "cn=directory manager" -b >>>>>>>>>>> "dc=our,dc=personal,dc=domain" '(objectclass=nsTombstone)' >>>>>>>>>>> Enter LDAP Password: >>>>>>>>>>> dn: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=our,dc=personal,dc=domain >>>>>>>>>>> >>>>>>>>>>> objectClass: top >>>>>>>>>>> objectClass: nsTombstone >>>>>>>>>>> objectClass: extensibleobject >>>>>>>>>>> nsds50ruv: {replicageneration} 50ef13ae000000040000 >>>>>>>>>>> nsds50ruv: {replica 4 ldap://master.our.personal.domain:389} >>>>>>>>>>> 5164d147000000040000 5447bda 8000100040000 >>>>>>>>>>> nsds50ruv: {replica 22 >>>>>>>>>>> ldap://separatenode.our.personal.domain:389} >>>>>>>>>>> 54107f9f000000160000 54436b 25000000160000 >>>>>>>>>>> nsds50ruv: {replica 21 >>>>>>>>>>> ldap://iparepbackup.our.personal.domain:389} >>>>>>>>>>> 51b734de000000150000 51b7 34ef000200150000 >>>>>>>>>>> nsds50ruv: {replica 19 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> 510d56c9000100130000 >>>>>>>>>>> 510d82 be000200130000 >>>>>>>>>>> nsds50ruv: {replica 18 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 17 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 16 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 15 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 14 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 13 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 12 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> nsds50ruv: {replica 23 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} >>>>>>>>>>> 54187702000200170000 >>>>>>>>>>> 541878 9a000000170000 >>>>>>>>>>> dc: our >>>>>>>>>>> nsruvReplicaLastModified: {replica 4 >>>>>>>>>>> ldap://master.our.personal.domain:389} 5447bce8 >>>>>>>>>>> nsruvReplicaLastModified: {replica 22 >>>>>>>>>>> ldap://separatenode.our.personal.domain:389} 54436a5e >>>>>>>>>>> nsruvReplicaLastModified: {replica 21 >>>>>>>>>>> ldap://iparepbackup.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 19 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 18 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 17 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 16 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 15 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 14 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 13 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 12 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> nsruvReplicaLastModified: {replica 23 >>>>>>>>>>> ldap://host-in-question.our.personal.domain:389} 00000000 >>>>>>>>>>> >>>>>>>>>>> dn: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>>>> >>>>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>>>> objectClass: top >>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>> objectClass: nsTombstone >>>>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>>>> >>>>>>>>>>> dn: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste >>>>>>>>>>> >>>>>>>>>>> rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain >>>>>>>>>>> objectClass: top >>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>> objectClass: nsTombstone >>>>>>>>>>> cn: host-in-question.our.personal.domain >>>>>>>>>>> nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0 >>>>>>>>>>> >>>>>>>>>>> As you can see, the "host-in-question" has many RUV's and of which >>>>>>>>>>> two >>>>>>>>>>> appear to be "active" and two entries which I believe (pardon my >>>>>>>>>>> ignorance) possibly correlate with the "active" entries of the >>>>>>>>>>> "host-in-question". >>>>>>>>>>> >>>>>>>>>>> Do these two tombstone entries need to be deleted with ldapdelete >>>>>>>>>>> before we can re-provision "host-in-question" and add it back as a >>>>>>>>>>> replica? >>>>>>>> >>>>>>>> No, you cannot delete tombstones manually. They will be cleaned up >>>>>>>> at some >>>>>>>> point by the dirsrv tombstone reap thread, and they should not be >>>>>>>> interfering with anything. >>>>>>>> >>>>>>>> What is the real problem you have? Did replication stop working? Are >>>>>>>> you >>>>>>>> getting error messages? >>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> John DeSantis >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >> >> From rcritten at redhat.com Mon Nov 24 16:04:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Nov 2014 11:04:50 -0500 Subject: [Freeipa-users] curious about monkeysphere In-Reply-To: References: Message-ID: <54735722.8060004@redhat.com> Outback Dingo wrote: > ??Im curious about monkeysphere http://web.monkeysphere.info/ and how > it might compare, integrate, enhance freeipa ..... any thoughts, or > ideas, or is what it does basically already covered via freeipa? > > There does seem to be a fair bit of overlap with the SSH key distribituion/validation. We attempt CA fetching in a similar way, by using a trusted mechanism to fetch it. We use Kerberos when available. rob From yamakasi.014 at gmail.com Mon Nov 24 16:36:48 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 24 Nov 2014 17:36:48 +0100 Subject: [Freeipa-users] Add extra infofield to user Message-ID: Hi All, I see it's possible to add an extra field to a user by creating a new userobjectclass. The issue is that this field is not yet @ the user, but can we create it here ? /usr/lib/python2.6/site-packages/ipalib/plugins/user.py Any direction would be great! Thanks, Matt From mariajose1982 at gmail.com Mon Nov 24 16:45:15 2014 From: mariajose1982 at gmail.com (=?UTF-8?Q?Maria_Jose_Ya=C3=B1ez_Dacosta?=) Date: Mon, 24 Nov 2014 14:45:15 -0200 Subject: [Freeipa-users] Setting up a Kerberized IMAP Server. Message-ID: Thank you for your prompt reply :). I still don't discover what caused the problem, but now I could get more information about the problem. I run the command that you commented me, I did as follows: - kinit usuipa - kvno imap/zimbrafreeipa.example.com at FI.example.com (I said in my previous mail fi.example.com but should have said zimbrafreeipa.example.com. Forgiveness!!). Then run klist and got this: 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/FI.EXAMPLE.COM at FI.EXAMPLE.COM 11/24/14 14:05:52 11/25/14 14:04:50 imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM Then run KRB5_TRACE=/dev/stdout kvno imap/zimbrafreeipa.example.com at FI.EXAMPLE.COM and got this: --------------------------------------- OUTPUT --------------------------------------------------------------- [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0 [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: 0/Conseguido imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 --------------------------------------- END OF OUTPUT --------------------------------------------------- When I rum KRB5_TRACE=/dev/stdout thunderbird this show: --------------------------------------- OUTPUT --------------------------------------------------------------- Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: no se puede abrir el fichero del objeto compartido: No existe el fichero o el directorio [20906] 1416845377.323420: ccselect module realm chose cache FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0 [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: 0/Conseguido [20906] 1416845377.325617: Creating authenticator for usuipa at FI.EXAMPLE.COM -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, subkey aes256-cts/3BB4, session key aes256-cts/A007 [20906] 1416845377.353847: ccselect module realm chose cache FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey (null), seqnum 1067232298 [20906] 1416845396.10173: ccselect module realm chose cache FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0 [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: 0/Conseguido [20906] 1416845396.10469: Creating authenticator for usuipa at FI.EXAMPLE.COM -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, subkey aes256-cts/5F4D, session key aes256-cts/A007 [20906] 1416845396.35033: ccselect module realm chose cache FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey (null), seqnum 911725412 --------------------------------------- END OF OUTPUT --------------------------------------------------- About permissions on keytab file, I have as following: ls -l /opt/zimbra/conf/krb5.keytab -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab Selinux (/etc/selinux/config) SELINUX=disabled What do you think about this?, I'm forgetting to do something?. Have a nice day you too ^.^, and thanks for you help!. -- Maria Jos? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 24 16:51:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 24 Nov 2014 11:51:20 -0500 Subject: [Freeipa-users] Add extra infofield to user In-Reply-To: References: Message-ID: <54736208.4020109@redhat.com> On 11/24/2014 11:36 AM, Matt . wrote: > Hi All, > > I see it's possible to add an extra field to a user by creating a new > userobjectclass. > > The issue is that this field is not yet @ the user, but can we create it here ? > > /usr/lib/python2.6/site-packages/ipalib/plugins/user.py > > Any direction would be great! > > Thanks, > > Matt > You need to extend schema. You add new attribute and put it to the object class that is Extensible object. However it is usually better yo use something that is already in the directory server. What is the contents that you want to add? May be there is already something you can use. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Mon Nov 24 17:42:47 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 24 Nov 2014 18:42:47 +0100 Subject: [Freeipa-users] Add extra infofield to user In-Reply-To: <54736208.4020109@redhat.com> References: <54736208.4020109@redhat.com> Message-ID: Hi Dimitri, I need to use multiple email adresses, but not under mail, mail needs to be primary. I have seen I can add mailAttribute ? I need to have them as field, and the best would be something like alias1, alias2, aliasX Would be doable ? Cheers, Matt 2014-11-24 17:51 GMT+01:00 Dmitri Pal : > On 11/24/2014 11:36 AM, Matt . wrote: >> >> Hi All, >> >> I see it's possible to add an extra field to a user by creating a new >> userobjectclass. >> >> The issue is that this field is not yet @ the user, but can we create it >> here ? >> >> /usr/lib/python2.6/site-packages/ipalib/plugins/user.py >> >> Any direction would be great! >> >> Thanks, >> >> Matt >> > > You need to extend schema. > You add new attribute and put it to the object class that is Extensible > object. > However it is usually better yo use something that is already in the > directory server. > > What is the contents that you want to add? May be there is already something > you can use. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > 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 From cosmefc at gmail.com Mon Nov 24 18:01:39 2014 From: cosmefc at gmail.com (=?UTF-8?B?Q29zbWUgRmFyaWEgQ29ycsOqYQ==?=) Date: Mon, 24 Nov 2014 13:01:39 -0500 Subject: [Freeipa-users] Freeipa and EDUROAM In-Reply-To: References: <54710571.8000605@gmail.com> Message-ID: <54737283.9000206@gmail.com> Hi, EDUROAM (education roaming) is an international roaming service for users in research, higher education and further education. It use Openldap, freeradius, radsec to support this objective. I would like to expand this to create a better infrastructure for our network, in special wireless network. Do you have some experience with openldap to freeipa migration? TIA. On 11/22/2014 05:13 PM, Outback Dingo wrote: > > > On Sun, Nov 23, 2014 at 8:51 AM, Cosme Corr?a > wrote: > > Hi, > > I am an "EDUROAM administrator". > We use openldap, but i would like to migrate to freeipa. > > Has anyone done this before? > > Any help would be greatly appreciated. > > > can you help define what eduroam is? are you referring to the > federated wireless network infrastructures being deployed by > universities around the world? > > > > -- > Cosme Faria Corr?a > > > -- > 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 > > -- Cosme Faria Corr?a -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.veri at gmail.com Mon Nov 24 18:13:58 2014 From: andrea.veri at gmail.com (Andrea Veri) Date: Mon, 24 Nov 2014 19:13:58 +0100 Subject: [Freeipa-users] Freeipa and EDUROAM In-Reply-To: <54737283.9000206@gmail.com> References: <54710571.8000605@gmail.com> <54737283.9000206@gmail.com> Message-ID: You might be interested in the following links ([1] and [2]) which refer to the very recent GNOME Infrastructure's migration from OpenLDAP to FreeIPA. cheers, [1] https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ [2] https://www.dragonsreach.it/2014/10/12/the-gnome-infrastructures-freeipa-move-behind-the-scenes/ 2014-11-24 19:01 GMT+01:00 Cosme Faria Corr?a : > Hi, > > EDUROAM (education roaming) is an international roaming service for users in > research, higher education and further education. > It use Openldap, freeradius, radsec to support this objective. > > I would like to expand this to create a better infrastructure for our > network, in special wireless network. > > Do you have some experience with openldap to freeipa migration? > > TIA. > > > > > > > > On 11/22/2014 05:13 PM, Outback Dingo wrote: > > > > On Sun, Nov 23, 2014 at 8:51 AM, Cosme Corr?a wrote: >> >> Hi, >> >> I am an "EDUROAM administrator". >> We use openldap, but i would like to migrate to freeipa. >> >> Has anyone done this before? >> >> Any help would be greatly appreciated. > > > can you help define what eduroam is? are you referring to the federated > wireless network infrastructures being deployed by universities around the > world? > >> >> >> >> -- >> Cosme Faria Corr?a >> >> >> -- >> 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 > > > > -- > Cosme Faria Corr?a > > > -- > 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 From rcritten at redhat.com Mon Nov 24 18:19:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Nov 2014 13:19:40 -0500 Subject: [Freeipa-users] Freeipa and EDUROAM In-Reply-To: <54737283.9000206@gmail.com> References: <54710571.8000605@gmail.com> <54737283.9000206@gmail.com> Message-ID: <547376BC.1030106@redhat.com> Cosme Faria Corr?a wrote: > Hi, > > EDUROAM (education roaming) is an international roaming service for > users in research, higher education and further education. > It use Openldap, freeradius, radsec to support this objective. > > I would like to expand this to create a better infrastructure for our > network, in special wireless network. > > Do you have some experience with openldap to freeipa migration? It is a little out-of-date but check out http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html rob > > TIA. > > > > > > > On 11/22/2014 05:13 PM, Outback Dingo wrote: >> >> >> On Sun, Nov 23, 2014 at 8:51 AM, Cosme Corr?a > > wrote: >> >> Hi, >> >> I am an "EDUROAM administrator". >> We use openldap, but i would like to migrate to freeipa. >> >> Has anyone done this before? >> >> Any help would be greatly appreciated. >> >> >> can you help define what eduroam is? are you referring to the >> federated wireless network infrastructures being deployed by >> universities around the world? >> >> >> >> >> -- >> Cosme Faria Corr?a >> >> >> -- >> 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 >> >> > > -- > Cosme Faria Corr?a > > > From dpal at redhat.com Mon Nov 24 18:22:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 24 Nov 2014 13:22:52 -0500 Subject: [Freeipa-users] Add extra infofield to user In-Reply-To: References: <54736208.4020109@redhat.com> Message-ID: <5473777C.7010603@redhat.com> On 11/24/2014 12:42 PM, Matt . wrote: > Hi Dimitri, > > I need to use multiple email adresses, but not under mail, mail needs > to be primary. > > I have seen I can add mailAttribute ? > > I need to have them as field, and the best would be something like > alias1, alias2, aliasX The attributes can be multivalued. Do you need to know which is which? I mean if you have mail1 and mail2 do you need to be sure that mail1 is alias1 and mail2 is alias2 or they are interchangeable and the order does not really matter? Then multivalued attribute would be the way to go. Also there is a concept of attribute subtypes that might help here. But I would leave to LDAP gurus to chime in on this matter. > > Would be doable ? > > Cheers, > > Matt > > > > 2014-11-24 17:51 GMT+01:00 Dmitri Pal : >> On 11/24/2014 11:36 AM, Matt . wrote: >>> Hi All, >>> >>> I see it's possible to add an extra field to a user by creating a new >>> userobjectclass. >>> >>> The issue is that this field is not yet @ the user, but can we create it >>> here ? >>> >>> /usr/lib/python2.6/site-packages/ipalib/plugins/user.py >>> >>> Any direction would be great! >>> >>> Thanks, >>> >>> Matt >>> >> You need to extend schema. >> You add new attribute and put it to the object class that is Extensible >> object. >> However it is usually better yo use something that is already in the >> directory server. >> >> What is the contents that you want to add? May be there is already something >> you can use. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Mon Nov 24 18:27:03 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 24 Nov 2014 19:27:03 +0100 Subject: [Freeipa-users] Add extra infofield to user In-Reply-To: <5473777C.7010603@redhat.com> References: <54736208.4020109@redhat.com> <5473777C.7010603@redhat.com> Message-ID: Hi, I need to make sure I have a primary one which is mail, the other ones should not matter, but I think it's wiser to have it like I know what is where. The reason why I need to is because I'm using Kolab which needs at least a primary mail attribute. Cheers, Matt 2014-11-24 19:22 GMT+01:00 Dmitri Pal : > On 11/24/2014 12:42 PM, Matt . wrote: >> >> Hi Dimitri, >> >> I need to use multiple email adresses, but not under mail, mail needs >> to be primary. >> >> I have seen I can add mailAttribute ? >> >> I need to have them as field, and the best would be something like >> alias1, alias2, aliasX > > > The attributes can be multivalued. > Do you need to know which is which? I mean if you have mail1 and mail2 do > you need to be sure that mail1 is alias1 and mail2 is alias2 or they are > interchangeable and the order does not really matter? Then multivalued > attribute would be the way to go. > > Also there is a concept of attribute subtypes that might help here. > > But I would leave to LDAP gurus to chime in on this matter. > > >> >> Would be doable ? >> >> Cheers, >> >> Matt >> >> >> >> 2014-11-24 17:51 GMT+01:00 Dmitri Pal : >>> >>> On 11/24/2014 11:36 AM, Matt . wrote: >>>> >>>> Hi All, >>>> >>>> I see it's possible to add an extra field to a user by creating a new >>>> userobjectclass. >>>> >>>> The issue is that this field is not yet @ the user, but can we create it >>>> here ? >>>> >>>> /usr/lib/python2.6/site-packages/ipalib/plugins/user.py >>>> >>>> Any direction would be great! >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>> You need to extend schema. >>> You add new attribute and put it to the object class that is Extensible >>> object. >>> However it is usually better yo use something that is already in the >>> directory server. >>> >>> What is the contents that you want to add? May be there is already >>> something >>> you can use. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> -- >>> 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 > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From dpal at redhat.com Mon Nov 24 18:33:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 24 Nov 2014 13:33:50 -0500 Subject: [Freeipa-users] Add extra infofield to user In-Reply-To: References: <54736208.4020109@redhat.com> <5473777C.7010603@redhat.com> Message-ID: <54737A0E.4050407@redhat.com> On 11/24/2014 01:27 PM, Matt . wrote: > Hi, > > I need to make sure I have a primary one which is mail, the other ones > should not matter, but I think it's wiser to have it like I know what > is where. > > The reason why I need to is because I'm using Kolab which needs at > least a primary mail attribute. The point is that you can have the primary one in one attribute and then the rest in a different multi value attribute. If for example you use the primary mail as uid and aliases as mail then you can solve the problem. But that means your logn names will be mails. This might be fine might not. May be you use some other attribute to store primary mail. Here is the pointer on how to do it: http://www.freeipa.org/page/HowTo/Add_a_new_attribute > > Cheers, > > Matt > > 2014-11-24 19:22 GMT+01:00 Dmitri Pal : >> On 11/24/2014 12:42 PM, Matt . wrote: >>> Hi Dimitri, >>> >>> I need to use multiple email adresses, but not under mail, mail needs >>> to be primary. >>> >>> I have seen I can add mailAttribute ? >>> >>> I need to have them as field, and the best would be something like >>> alias1, alias2, aliasX >> >> The attributes can be multivalued. >> Do you need to know which is which? I mean if you have mail1 and mail2 do >> you need to be sure that mail1 is alias1 and mail2 is alias2 or they are >> interchangeable and the order does not really matter? Then multivalued >> attribute would be the way to go. >> >> Also there is a concept of attribute subtypes that might help here. >> >> But I would leave to LDAP gurus to chime in on this matter. >> >> >>> Would be doable ? >>> >>> Cheers, >>> >>> Matt >>> >>> >>> >>> 2014-11-24 17:51 GMT+01:00 Dmitri Pal : >>>> On 11/24/2014 11:36 AM, Matt . wrote: >>>>> Hi All, >>>>> >>>>> I see it's possible to add an extra field to a user by creating a new >>>>> userobjectclass. >>>>> >>>>> The issue is that this field is not yet @ the user, but can we create it >>>>> here ? >>>>> >>>>> /usr/lib/python2.6/site-packages/ipalib/plugins/user.py >>>>> >>>>> Any direction would be great! >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>> You need to extend schema. >>>> You add new attribute and put it to the object class that is Extensible >>>> object. >>>> However it is usually better yo use something that is already in the >>>> directory server. >>>> >>>> What is the contents that you want to add? May be there is already >>>> something >>>> you can use. >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> -- >>>> 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 >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From CWhite at skytouchtechnology.com Mon Nov 24 19:27:50 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 24 Nov 2014 19:27:50 +0000 Subject: [Freeipa-users] sssd.conf question Message-ID: Starting to look at managing IPA requisites from Puppet - especially because I have seen SSSD silently quit. So if I manage /etc/sssd/sssd.conf file with puppet, I have 2 IPA servers (with what appears to be a fully functioning MMR), 01 and 02. Can I arbitrarily change the 'ipa_server' listed in sssd.conf? Restart SSSD if I touch the file with puppet? Anything else I should know? I obviously will manage /etc/nsswitch.conf and possibly /etc/pam.d/system-auth-ac if anyone has been down this road with things to watch for. Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From jhrozek at redhat.com Mon Nov 24 19:43:39 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 24 Nov 2014 20:43:39 +0100 Subject: [Freeipa-users] sssd.conf question In-Reply-To: References: Message-ID: <20141124194339.GO20167@hendrix.brq.redhat.com> On Mon, Nov 24, 2014 at 07:27:50PM +0000, Craig White wrote: > Starting to look at managing IPA requisites from Puppet - especially because I have seen SSSD silently quit. Are there any errors in either the sssd logs or the syslog? > > So if I manage /etc/sssd/sssd.conf file with puppet, I have 2 IPA servers (with what appears to be a fully functioning MMR), 01 and 02. Can I arbitrarily change the 'ipa_server' listed in sssd.conf? Restart SSSD if I touch the file with puppet? Anything else I should know? You can do that, but why switch the order? Isn't it better to let SSSD autodiscover the serves with SRV records? From CWhite at skytouchtechnology.com Mon Nov 24 19:57:01 2014 From: CWhite at skytouchtechnology.com (Craig White) Date: Mon, 24 Nov 2014 19:57:01 +0000 Subject: [Freeipa-users] sssd.conf question In-Reply-To: <20141124194339.GO20167@hendrix.brq.redhat.com> References: <20141124194339.GO20167@hendrix.brq.redhat.com> Message-ID: <118e50005c874394bb9addf30b1fc9eb@BLUPR08MB488.namprd08.prod.outlook.com> -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek Sent: Monday, November 24, 2014 12:44 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] sssd.conf question On Mon, Nov 24, 2014 at 07:27:50PM +0000, Craig White wrote: > Starting to look at managing IPA requisites from Puppet - especially because I have seen SSSD silently quit. Are there any errors in either the sssd logs or the syslog? ---- Haven't checked yet - it's only happened a few times. One of the things that I can accomplish with puppet is to ensure the SSSD service is running (restarted if it quits). ---- > > So if I manage /etc/sssd/sssd.conf file with puppet, I have 2 IPA servers (with what appears to be a fully functioning MMR), 01 and 02. Can I arbitrarily change the 'ipa_server' listed in sssd.conf? Restart SSSD if I touch the file with puppet? Anything else I should know? You can do that, but why switch the order? Isn't it better to let SSSD autodiscover the serves with SRV records? ---- Sure but it seems that a specific entry is auto-created on each of the machines joined to IPA like this one-line clip from sssd.conf ipa_server = _srv_, ipa01.stt.local Should I just have _srv_ and not any specific ipa servers listed there? Thanks Craig From jhrozek at redhat.com Mon Nov 24 20:00:05 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 24 Nov 2014 21:00:05 +0100 Subject: [Freeipa-users] sssd.conf question In-Reply-To: <118e50005c874394bb9addf30b1fc9eb@BLUPR08MB488.namprd08.prod.outlook.com> References: <20141124194339.GO20167@hendrix.brq.redhat.com> <118e50005c874394bb9addf30b1fc9eb@BLUPR08MB488.namprd08.prod.outlook.com> Message-ID: <20141124200005.GP20167@hendrix.brq.redhat.com> On Mon, Nov 24, 2014 at 07:57:01PM +0000, Craig White wrote: > You can do that, but why switch the order? Isn't it better to let SSSD autodiscover the serves with SRV records? > ---- > Sure but it seems that a specific entry is auto-created on each of the machines joined to IPA like this one-line clip from sssd.conf > > ipa_server = _srv_, ipa01.stt.local > > Should I just have _srv_ and not any specific ipa servers listed there? Depends on what do you want the clients to do :-) What the directive says is: 1. _srv_ -- autodiscover the servers using DNS SRV records 2 ipa01.stt.local -- if that fails, connect directly to this server Hopefully the 'failover' sections in sssd man pages are also helpful. From william.muriithi at gmail.com Tue Nov 25 01:38:56 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 24 Nov 2014 20:38:56 -0500 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy? Message-ID: <20141125013856.6041749.17897.9249@gmail.com> An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Tue Nov 25 02:07:38 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 25 Nov 2014 02:07:38 +0000 (UTC) Subject: [Freeipa-users] Don't know what To do with this (error?? ) Message-ID: <1584689302.507006.1416881258943.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Goodmorning? So I've solved my Time error (I think) in my fedora 20, but even though I'm having the correct time and configured the browser for kerberos authentication I still can't log in my admin account in the web UI? is there a work around for this??? plus I can't find any solutions online on this matter, so I'm really confused on why this is happening in my free ipa : -------------- next part -------------- A non-text attachment was scrubbed... Name: solveitpls.png Type: image/png Size: 171967 bytes Desc: not available URL: From harvero at gmail.com Tue Nov 25 02:23:55 2014 From: harvero at gmail.com (Bob) Date: Mon, 24 Nov 2014 21:23:55 -0500 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy? In-Reply-To: <20141125013856.6041749.17897.9249@gmail.com> References: <20141125013856.6041749.17897.9249@gmail.com> Message-ID: List more than 1 LDAP sever in you config then. ldap_uri, ldap_backup_uri (string) Specifies the comma-separated list of URIs of the LDAP servers to which SSSD should connect in the order of preference. Refer to the "FAILOVER" section for more information on failover and server redundancy. If neither option is specified, service discovery is enabled. For more information, refer to the "SERVICE DISCOVERY" section. The format of the URI must match the format defined in RFC 2732: ldap[s]://[:port] For explicit IPv6 addresses, must be enclosed in brackets [] example: ldap://[fc00::126:25]:389 On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < william.muriithi at gmail.com> wrote: > Evening, > > After looking at almost all the SUDO documentation I could find, it looks > one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red > hat advice to add in sssd config file. > > ?services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] > sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com > ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com > ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ > tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM > krb5_server = grobi.idm.coe.muc.redhat.com > > The implications ?of adding above is that SUDO would break if the > hardcoded ipa is not available even if there is another replica somewhere > in the network. Is that correct assumption? > > Is there a better way of doing it that I have missed? > > Thanks > > William > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Nov 25 04:43:28 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 25 Nov 2014 14:43:28 +1000 Subject: [Freeipa-users] curious about monkeysphere In-Reply-To: <54735722.8060004@redhat.com> References: <54735722.8060004@redhat.com> Message-ID: <20141125044328.GA8412@dhcp-40-8.bne.redhat.com> On Mon, Nov 24, 2014 at 11:04:50AM -0500, Rob Crittenden wrote: > Outback Dingo wrote: > > ??Im curious about monkeysphere http://web.monkeysphere.info/ and how > > it might compare, integrate, enhance freeipa ..... any thoughts, or > > ideas, or is what it does basically already covered via freeipa? > > > > > > There does seem to be a fair bit of overlap with the SSH key > distribituion/validation. > > We attempt CA fetching in a similar way, by using a trusted mechanism to > fetch it. We use Kerberos when available. > > rob > The projects have very different goals - Monkeysphere is web-of-trust whereas FreeIPA uses centralised authentication and a chain-of-trust PKI - so I do not see much scope for direct integration. Rob's point about some of the underlying mechanisms being similar is accurate - a cross-pollination of ideas or implementations could reduce overall effort. Fraser From mkosek at redhat.com Tue Nov 25 07:07:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 08:07:46 +0100 Subject: [Freeipa-users] Don't know what To do with this (error?? ) In-Reply-To: <1584689302.507006.1416881258943.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> References: <1584689302.507006.1416881258943.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Message-ID: <54742AC2.3060002@redhat.com> On 11/25/2014 03:07 AM, Rolf Nufable wrote: > Goodmorning > So I've solved my Time error (I think) in my fedora 20, but even though I'm having the correct time and configured the browser for kerberos authentication I still can't log in my admin account in the web UI > is there a work around for this?? Well, you can log in with your user name and password if GSSAPI does not work. Or is that part also not working? If this is the case, I would suggest to: - check that ipa_memcached service is running - check that there are no SELinux errors in audit.log (or just try in SELinux permissive mode) If user+password login works and GSSAPI does not, make sure that after you fixed the time on your FreeIPA server, you also have time synchronized on your machine with the browser - so that there is not time difference bigger that a 1-2 minutes. > plus I can't find any solutions online on this matter, so I'm really confused on why this is happening in my free ipa :< > TIA : ) From rolf_16_nufable at yahoo.com Tue Nov 25 07:12:23 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Mon, 24 Nov 2014 23:12:23 -0800 Subject: [Freeipa-users] Don't know what To do with this (error?? ) In-Reply-To: <54742AC2.3060002@redhat.com> Message-ID: <1416899543.9132.YahooMailAndroidMobile@web161606.mail.bf1.yahoo.com> Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? Sent from Yahoo Mail on Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 25 07:55:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 08:55:04 +0100 Subject: [Freeipa-users] Don't know what To do with this (error?? ) In-Reply-To: <1416899543.9132.YahooMailAndroidMobile@web161606.mail.bf1.yahoo.com> References: <1416899543.9132.YahooMailAndroidMobile@web161606.mail.bf1.yahoo.com> Message-ID: <547435D8.3080400@redhat.com> On 11/25/2014 08:12 AM, Rolf Nufable wrote: > Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? > > Sent from Yahoo Mail on Android Well, you need to have a ticket on your client machine (the one with the browser) to be able to authenticate via Kerberos. You can check that with # klist To get the ticket, you can either run the kinit manually as you said or let SSSD to get it for you as you authenticate/login to your client machine. AFAIK, this is default behavior. Martin From rolf_16_nufable at yahoo.com Tue Nov 25 07:59:27 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Tue, 25 Nov 2014 07:59:27 +0000 (UTC) Subject: [Freeipa-users] Don't know what To do with this (error?? ) In-Reply-To: <547435D8.3080400@redhat.com> References: <547435D8.3080400@redhat.com> Message-ID: <1156877372.623540.1416902367456.JavaMail.yahoo@jws10635.mail.bf1.yahoo.com> ohh sorry I didn't said that I was using the freeipa server on this problem, anyway thanks for the replies :) and before? Thanks, really appreciate it :D On Monday, November 24, 2014 11:55 PM, Martin Kosek wrote: On 11/25/2014 08:12 AM, Rolf Nufable wrote: > Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? > > Sent from Yahoo Mail on Android Well, you need to have a ticket on your client machine (the one with the browser) to be able to authenticate via Kerberos. You can check that with # klist To get the ticket, you can either run the kinit manually as you said or let SSSD to get it for you as you authenticate/login to your client machine. AFAIK, this is default behavior. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Nov 25 08:02:59 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 25 Nov 2014 09:02:59 +0100 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy? In-Reply-To: <20141125013856.6041749.17897.9249@gmail.com> References: <20141125013856.6041749.17897.9249@gmail.com> Message-ID: <20141125080259.GB2590@mail.corp.redhat.com> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < william.muriithi at gmail.com> wrote: > Evening, > > After looking at almost all the SUDO documentation I could find, it looks > one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red > hat advice to add in sssd config file. > > services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] > sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com > ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com > ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ > tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM > krb5_server = grobi.idm.coe.muc.redhat.com > > The implications of adding above is that SUDO would break if the > hardcoded ipa is not available even if there is another replica somewhere > in the network. Is that correct assumption? > > Is there a better way of doing it that I have missed? > Which version of sssd do you have? sssd >= 1.10 has native ipa suod providers and you don't need to use "sudo_provider = ldap". LS From pspacek at redhat.com Tue Nov 25 09:11:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Nov 2014 10:11:42 +0100 Subject: [Freeipa-users] Setting up a Kerberized IMAP Server. In-Reply-To: References: Message-ID: <547447CE.8090400@redhat.com> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: > Thank you for your prompt reply :). > > I still don't discover what caused the problem, but now I could get more > information about the problem. > > I run the command that you commented me, I did as follows: > > - kinit usuipa > - kvno imap/zimbrafreeipa.example.com at FI.example.com > > (I said in my previous mail fi.example.com but should have said > zimbrafreeipa.example.com. > Forgiveness!!). > > Then run klist and got this: > > 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/FI.EXAMPLE.COM at FI.EXAMPLE.COM > 11/24/14 14:05:52 11/25/14 14:04:50 imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > Then run > KRB5_TRACE=/dev/stdout kvno imap/zimbrafreeipa.example.com at FI.EXAMPLE.COM > and got this: > --------------------------------------- OUTPUT > --------------------------------------------------------------- > [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0 > [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > result: 0/Conseguido > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 > --------------------------------------- END OF OUTPUT > --------------------------------------------------- > > When I rum > KRB5_TRACE=/dev/stdout thunderbird > this show: > > --------------------------------------- OUTPUT > --------------------------------------------------------------- > Gtk-Message: Failed to load module "canberra-gtk-module": > libcanberra-gtk-module.so: no se puede abrir el fichero del objeto > compartido: No existe el fichero o el directorio > [20906] 1416845377.323420: ccselect module realm chose cache > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > FILE:/tmp/krb5cc_0 > [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > result: 0/Conseguido > [20906] 1416845377.325617: Creating authenticator for usuipa at FI.EXAMPLE.COM > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, > subkey aes256-cts/3BB4, session key aes256-cts/A007 > [20906] 1416845377.353847: ccselect module realm chose cache > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey > (null), seqnum 1067232298 > [20906] 1416845396.10173: ccselect module realm chose cache > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0 > [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > result: 0/Conseguido > [20906] 1416845396.10469: Creating authenticator for usuipa at FI.EXAMPLE.COM > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, > subkey aes256-cts/5F4D, session key aes256-cts/A007 > [20906] 1416845396.35033: ccselect module realm chose cache > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for server > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey > (null), seqnum 911725412 > > --------------------------------------- END OF OUTPUT > --------------------------------------------------- This seems okay, Thunderbird got necessary ticket so the problem could be on server side. (Just to be 100% sure: Did you configure network.negotiate-auth option in Thunderbird according to https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) > About permissions on keytab file, I have as following: > > ls -l /opt/zimbra/conf/krb5.keytab > -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab > > Selinux (/etc/selinux/config) > SELINUX=disabled > > What do you think about this?, That it is completely insecure :-) Seriously, keytab contains symmetric cryptographic keys so it should be protected as much as feasible. It is fine for testing purposes (assuming that you do not forget to secure file permissions and generate new keytab before moving it to production). As a next step please raise debug levels on the server and possibly use KRB5_TRACE=/dev/stdout trick for IMAP server process. -- Petr^2 Spacek From mariajose1982 at gmail.com Tue Nov 25 18:02:49 2014 From: mariajose1982 at gmail.com (=?UTF-8?Q?Maria_Jose_Ya=C3=B1ez_Dacosta?=) Date: Tue, 25 Nov 2014 16:02:49 -0200 Subject: [Freeipa-users] Freeipa-users Digest, Vol 76, Issue 111 In-Reply-To: References: Message-ID: Sorry for delay in answering, I've been testing a few things before going back to ask. Thanks for the advice, I'll be careful with security :). I also tried as is explained in the url you shared with me and as you suspected that isn't the problem either. I installed Wireshark, packet capture shows me these errors: error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) e-text: PREAUTH_FAILED Where the origin of these packages is the FreeIPA server and the destination is the Zimbra server. I think this may be causing problems. I'm ashamed to say this, but haven't known as I have to do to debug Imap process on the server using KRB5_TRACE. Thanks so much for all your help and if you have more suggestions, it would be appreciated. Have a good day. 2014-11-25 15:00 GMT-02:00 : > Send Freeipa-users mailing list submissions to > freeipa-users at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-users > or, via email, send a message with subject or body 'help' to > freeipa-users-request at redhat.com > > You can reach the person managing the list at > freeipa-users-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-users digest..." > > > Today's Topics: > > 1. Re: Is it possible to set up SUDO with redudancy? > (Lukas Slebodnik) > 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Nov 2014 09:02:59 +0100 > From: Lukas Slebodnik > To: William Muriithi > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Is it possible to set up SUDO with > redudancy? > Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> > Content-Type: text/plain; charset=utf-8 > > On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < > william.muriithi at gmail.com> wrote: > > > Evening, > > > > After looking at almost all the SUDO documentation I could find, it looks > > one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red > > hat advice to add in sssd config file. > > > > services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] > > sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com > > ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com > > ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ > > tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM > > krb5_server = grobi.idm.coe.muc.redhat.com > > > > The implications of adding above is that SUDO would break if the > > hardcoded ipa is not available even if there is another replica somewhere > > in the network. Is that correct assumption? > > > > Is there a better way of doing it that I have missed? > > > > Which version of sssd do you have? > sssd >= 1.10 has native ipa suod providers and you don't need to use > "sudo_provider = ldap". > > LS > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Nov 2014 10:11:42 +0100 > From: Petr Spacek > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. > Message-ID: <547447CE.8090400 at redhat.com> > Content-Type: text/plain; charset=windows-1252 > > On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: > > Thank you for your prompt reply :). > > > > I still don't discover what caused the problem, but now I could get more > > information about the problem. > > > > I run the command that you commented me, I did as follows: > > > > - kinit usuipa > > - kvno imap/zimbrafreeipa.example.com at FI.example.com > > > > (I said in my previous mail fi.example.com but should have said > > zimbrafreeipa.example.com. > > Forgiveness!!). > > > > Then run klist and got this: > > > > 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ > FI.EXAMPLE.COM at FI.EXAMPLE.COM > > 11/24/14 14:05:52 11/25/14 14:04:50 imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > > > Then run > > KRB5_TRACE=/dev/stdout kvno imap/ > zimbrafreeipa.example.com at FI.EXAMPLE.COM > > and got this: > > --------------------------------------- OUTPUT > > --------------------------------------------------------------- > > [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> > imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > FILE:/tmp/krb5cc_0 > > [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > > result: 0/Conseguido > > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 > > --------------------------------------- END OF OUTPUT > > --------------------------------------------------- > > > > When I rum > > KRB5_TRACE=/dev/stdout thunderbird > > this show: > > > > --------------------------------------- OUTPUT > > --------------------------------------------------------------- > > Gtk-Message: Failed to load module "canberra-gtk-module": > > libcanberra-gtk-module.so: no se puede abrir el fichero del objeto > > compartido: No existe el fichero o el directorio > > [20906] 1416845377.323420: ccselect module realm chose cache > > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > server > > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> > > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > > [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> > > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > > FILE:/tmp/krb5cc_0 > > [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > > result: 0/Conseguido > > [20906] 1416845377.325617: Creating authenticator for > usuipa at FI.EXAMPLE.COM > > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, > > subkey aes256-cts/3BB4, session key aes256-cts/A007 > > [20906] 1416845377.353847: ccselect module realm chose cache > > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > server > > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> > > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > > [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey > > (null), seqnum 1067232298 > > [20906] 1416845396.10173: ccselect module realm chose cache > > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > server > > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> > > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > > [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> > imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > FILE:/tmp/krb5cc_0 > > [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > > result: 0/Conseguido > > [20906] 1416845396.10469: Creating authenticator for > usuipa at FI.EXAMPLE.COM > > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, > > subkey aes256-cts/5F4D, session key aes256-cts/A007 > > [20906] 1416845396.35033: ccselect module realm chose cache > > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > server > > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > > [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> > > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > > [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey > > (null), seqnum 911725412 > > > > --------------------------------------- END OF OUTPUT > > --------------------------------------------------- > > This seems okay, Thunderbird got necessary ticket so the problem could be > on > server side. (Just to be 100% sure: Did you configure > network.negotiate-auth > option in Thunderbird according to > https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) > > > About permissions on keytab file, I have as following: > > > > ls -l /opt/zimbra/conf/krb5.keytab > > -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab > > > > Selinux (/etc/selinux/config) > > SELINUX=disabled > > > > What do you think about this?, > > That it is completely insecure :-) Seriously, keytab contains symmetric > cryptographic keys so it should be protected as much as feasible. > > It is fine for testing purposes (assuming that you do not forget to secure > file permissions and generate new keytab before moving it to production). > > As a next step please raise debug levels on the server and possibly use > KRB5_TRACE=/dev/stdout trick for IMAP server process. > > -- > Petr^2 Spacek > > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 76, Issue 111 > ********************************************** > -- Maria Jos? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.zin at savoirfairelinux.com Tue Nov 25 19:23:56 2014 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 25 Nov 2014 14:23:56 -0500 (EST) Subject: [Freeipa-users] backup procedure : procedure for a lost of primary master In-Reply-To: <1387135736.314769.1416943361254.JavaMail.root@mail> Message-ID: <1314324719.314929.1416943436864.JavaMail.root@mail> Hi, I read the backup procedure on http://www.freeipa.org/page/Backup_and_Restore. If I lose my first master, it is stated than: - Clean deployment from the lost server by removing all replication agreements with it. - Choose another FreeIPA Server with CA installed to become the first master - Nominate this master to be the one in charge or renewing certs and publishing CRLS. This is a manual procedure at the moment. - Follow standard installation procedure to deploy a new master on a hardware/VM of your choice How do I nominate this master to be the one in charge of renews certs and publishing CRLS? I didn't found the procedure. Also do I care to differentiate between the first master and other replica, if my IPA installation use an external root CA certificate (Windows AD in that case)? Regards, Nicolas Zin From dbischof at hrz.uni-kassel.de Tue Nov 25 19:32:09 2014 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Tue, 25 Nov 2014 20:32:09 +0100 (CET) Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: <546F5EF0.2020608@redhat.com> References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> <546DFF77.7090104@redhat.com> <546F193B.4020602@redhat.com> <546F5EF0.2020608@redhat.com> Message-ID: Hi, with the help of Thierry and Rich I managed to debug the running ns-slapd on Server1 (see below). The failing attempt of decoding the SASL data returns a not very fruitful "-1" (SASL_FAIL, "generic failure"). Any ideas? Short summary: Server1 = running IPA server Server2 = intended IPA replica Both machines run the exact same, up-to-date version of CentOS 6.6. However: I had to run "ipa-replica-install" _without_ the option "--setup-ca" (didn't work, installation failed with some obscure Perl error), so there's no ns-slapd instance running for PKI-IPA. May this be related? On Fri, 21 Nov 2014, Rich Megginson wrote: > On 11/21/2014 04:51 AM, thierry bordaz wrote: >> On 11/21/2014 10:59 AM, dbischof at hrz.uni-kassel.de wrote: >>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>>> On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: >>>>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>>>> >>>>>> Server1 successfully replicated to Server2, but Server2 fails to >>>>>> replicated to Server1. >>>>>> >>>>>> The replication Server2->Server1 is done with kerberos >>>>>> authentication. Server1 receives the replication session, >>>>>> successfully identify the replication manager, start to receives >>>>>> replication extop but suddenly closes the connection. >>>>>> >>>>>> >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from >>>>>> xxx to yyy >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >>>>>> nentries=0 etime=0 dn="krbprincipalname=xxx" >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >>>>>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >>>>>> filter="(objectClass=*)" attrs="supportedControl supportedExtension" >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >>>>>> oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >>>>>> nentries=0 etime=0 >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >>>>>> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >>>>>> function error. >>>>>> >>>>>> The reason of this closure is logged in server1 error log. sasl_decode >>>>>> fails to decode a received PDU. >>>>>> >>>>>> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet >>>>>> for connection 2980 >>>>>> >>>>>> I do not know why it fails but I wonder if the received PDU is not >>>>>> larger than the maximum configured value. The attribute >>>>>> nsslapd-maxsasliosize is set to 2Mb by default. Would it be >>>>>> possible to increase its value (5Mb) to see if it has an impact >>>>>> >>>>>> [...] >>>>> >>>>> I set nsslapd-maxsasliosize to 6164480 on both machines, but the >>>>> problem remains. >>>> >>>> The sasl-decode fails but the exact returned value is not logged. >>>> With standard version we may need to attach a debugger and then set a >>>> conditional breakpoint in sasl-decode just after conn->oparams.decode >>>> that will fire if result !=0. Now this can change the dynamic and >>>> possibly prevent the problem to occur again. The other option is to >>>> use an instrumented version to log this value. >>> >>> If I understand the mechanism correctly, Server1 needs to have debug >>> versions of the relevant packages (probably 389-ds-base and >>> cyrus-sasl) installed in order to track down the problem. >>> Unfortunately, my Server1 is in production use - if I break it, my >>> colleagues will grab forks and torches and be after me. A short >>> downtime would be ok, though. >>> >>> Is there something else I could do? >> >> Sure I do not want to trigger so much trouble ;-) >> >> >> I think my email was not clear. To go further we would need to know the >> exact reason why sasl_decode fails. I see two options: >> >> * Prepare a debug version, that would report in the error logs the >> returned valud of sasl_decode (when it fails). Except downtime to >> install the debug version, it has no impact in production. >> >> * Do a debug session (gdb) on Server1. The debug session will >> install a breakpoint at a specific place, let the server run, >> catch the sasl_decode failure and note the return code, exit from >> debugger. >> When the problem occurs, it happens regularly (each 5 seconds) so >> we should not have to wait long. >> That means that debugging Server1 should disturb production for 5 >> to 10 min. >> A detailed procedure to do the debug session is required. >> > For starters: > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > > Since this is IPA you will need debuginfo packages for ipa and slapi-nis > in addition to the ones for 389. > > Take a look at the Debugging Hangs section where it describes how to use > gdb to get a stack trace. If you can use that gdb command to get a > stack trace with the full debugging symbols (and if you don't know what > that means, just post the redacted stack trace somewhere and provide us > with a link to it), then you should be all ready to do a gdb session to > reproduce the error and "catch it in the act". Mit freundlichen Gruessen/With best regards, --Daniel. From mitkany at gmail.com Tue Nov 25 20:21:10 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 25 Nov 2014 15:21:10 -0500 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <542A5564.4070205@redhat.com> References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> <20140929171206.3eb8e5f7@willson.usersys.redhat.com> <542A5564.4070205@redhat.com> Message-ID: My case for HTTP load balancing is little different. Ideally I would like to use a real load balancer (A10 in this case) for balancing HTTP and HTTPS services. Would that be possible? Based on the info in this thread, and Apache configuration for IPA (ipa.conf) the following steps were performed - Added host for sso.example.com - Added service for HTTP/sso.example.com - added new entry for HTTP/sso.example.com to /etc/httpd/conf/ipa.keytab. This keytab is listed in the conf.d/ipa.conf under the Location '/ipa' groups of directives. ipa-getkeytab -s `hostname` -p HTTP/sso.example.com -k /etc/httpd/conf/ipa.keytab - modifed the conf.d/ipa-rewrite.conf and ipa-pki-proxy.conf to redirect requests to sso.example.com The login page loads but unfortunately authentication is failing with HTTP 401 (unauthorized) response from the server. I wonder what I am doing wrong. IPA ver is 3.0 running on CentOS 6.5, 64bit Thanks Dimitar On Tue, Sep 30, 2014 at 3:01 AM, Petr Spacek wrote: > On 29.9.2014 23:12, Simo Sorce wrote: > >> On Mon, 29 Sep 2014 23:25:08 +0300 >> Alexander Bokovoy wrote: >> >> On Mon, 29 Sep 2014, Mark Heslin wrote: >>> >>>> Folks, >>>> >>>> I'm looking for the best approach to take for configuring IdM >>>> clients to access web services (HTTP) >>>> with keytabs when a front-end load-balanced hostname is in place. >>>> >>>> I have a distributed OpenShift Enterprise configuration with three >>>> broker hosts (broker1, broker2, broker3) >>>> with all three configured as IdM clients. >>>> >>>> IdM is configured with one server (idm-srv1.example.com), one >>>> replica (idm-srv2.example.com); an HTTP service >>>> has been created for each broker host: >>>> >>>> # ipa service-add HTTP/broker1.example.com >>>> # ipa service-add HTTP/broker2.example.com >>>> # ipa service-add HTTP/broker3.example.com >>>> >>>> A DNS round-robin hostname called '*broker**.example.com*' has also >>>> been configured to distribute broker requests >>>> across the three brokers: >>>> >>>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 >>>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 >>>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 >>>> >>>> Effectively, this creates a DNS A record that acts as a pseudo DNS >>>> load-balancer. >>>> >>>> To access the HTTP services, we have been creating keytabs for for >>>> the first broker host: >>>> >>>> # ipa-getkeytab -s idm-srv1.example.com -p >>>> HTTP/*broker1*.example.com at EXAMPLE.COM >>>> -k >>>> /var/www/openshift/broker/httpd/conf.d/http.keytab >>>> >>>> and copying the keytab over to the other two OpenShift broker hosts. >>>> >>>> This all works fine but in the event that *broker1* should go down, >>>> the other broker hosts will lose access >>>> to the web service. Ideally, we would like to have web services use >>>> the more generic, "load balanced" >>>> hostname (*broker.example.com*) and in turn have the keytabs use >>>> this name as well. >>>> >>>> I tried creating an HTTP service using the "load balanced" hostname >>>> (*broker.example.com*) but that appears to fail >>>> due to *broker.example.com* not being a valid host within IdM: >>>> >>>> # ipa service-add HTTP/broker.example.com >>>> ipa: ERROR: The host 'broker.example.com' does not exist to add a >>>> service to. >>>> >>>> In the F18 FreeIPA guide it discusses creating a combined keytab >>>> file (Section 6.5.4) using ktutil: >>>> >>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_ >>>> Guide/managing-services.html#Using_the_Same_Service_ >>>> Principal_for_Multiple_Services >>>> >>>> but would that still work as intended should a broker host go down? >>>> >>>> The next section (6.5.5) mentions creating a keytab to create a >>>> service principal that can be used across multiple hosts: >>>> >>>> # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k >>>> /etc/httpd/conf/krb5.keytab -e des-cbc-crc >>>> >>>> Which seems more in-line with my thinking and exactly what we've >>>> been doing but again, if I try to do that >>>> using the "load balanced" hostname (*broker.example.com*) it fails >>>> sicne it's not a valid host within IdM. >>>> >>>> What is the best method to doing this? >>>> >>> Make a host named broker.example.com >>> ipa host-add broker.example.com --force >>> >>> --force will make sure to create the host object even if there is no >>> such name in the DNS. >>> >>> Then create services for this host. >>> >>> You'll need to set up your balancer hosts to use the proper service >>> principal instead of allowing them to construct the principal >>> themselves based on the hostname. >>> >> >> Even better tell them to not assume any name if the server name is NULL >> GSSAPI will try every key in the keytab. YUou can even force that >> behavior with a krb5 config hack even if the app insist setting a name >> by adding "ignore_acceptor_hostname true" in [libdefaults] >> > > I consider this as a 'workaround'. > > Even better option is to teach your client application to use DNS SRV > records instead of plain A records. SRV records allow you to do more fancy > things like non-equal load balancing etc. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 25 20:32:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 22:32:35 +0200 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> <20140929171206.3eb8e5f7@willson.usersys.redhat.com> <542A5564.4070205@redhat.com> Message-ID: <20141125203235.GV28400@redhat.com> On Tue, 25 Nov 2014, Dimitar Georgievski wrote: >My case for HTTP load balancing is little different. Ideally I would like >to use a real load balancer (A10 in this case) for balancing HTTP and HTTPS >services. >Would that be possible? > >Based on the info in this thread, and Apache configuration for IPA >(ipa.conf) the following steps were performed >- Added host for sso.example.com >- Added service for HTTP/sso.example.com >- added new entry for HTTP/sso.example.com to /etc/httpd/conf/ipa.keytab. >This keytab is listed in the conf.d/ipa.conf under the Location '/ipa' >groups of directives. > ipa-getkeytab -s `hostname` -p HTTP/sso.example.com -k >/etc/httpd/conf/ipa.keytab > >- modifed the conf.d/ipa-rewrite.conf and ipa-pki-proxy.conf to redirect >requests to sso.example.com > >The login page loads but unfortunately authentication is failing with HTTP >401 (unauthorized) response from the server. I wonder what I am doing wrong. Can you show your /var/log/krb5kdc.log, lines concerning HTTP/sso.example.com principal at the time you are trying to access IPA UI. FreeIPA limits service principals' ability to impersonate user principals (or any other principals). FreeIPA UI runs as HTTP/ principal and is given permission to impersonate user principal when talking to ldap/ service. This setup is explicit and requires additional configuration for those Kerberos principals which ask for additional access. For more detailed description read my article at http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html -- / Alexander Bokovoy From rcritten at redhat.com Tue Nov 25 20:43:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Nov 2014 15:43:58 -0500 Subject: [Freeipa-users] backup procedure : procedure for a lost of primary master In-Reply-To: <1314324719.314929.1416943436864.JavaMail.root@mail> References: <1314324719.314929.1416943436864.JavaMail.root@mail> Message-ID: <5474EA0E.6080101@redhat.com> Nicolas Zin wrote: > > Hi, > > I read the backup procedure on http://www.freeipa.org/page/Backup_and_Restore. If I lose my first master, it is stated than: > - Clean deployment from the lost server by removing all replication agreements with it. > - Choose another FreeIPA Server with CA installed to become the first master > - Nominate this master to be the one in charge or renewing certs and publishing CRLS. This is a manual procedure at the moment. > - Follow standard installation procedure to deploy a new master on a hardware/VM of your choice Yes, that's right. If the master is gone you'll need to use the --force command to remove the agreements. You may also need to do additional replication topology work to ensure that every master has at least one valid agreement. For example, if you have A <-> B <-> C and B dies, you'll need to connect A to C as well otherwise you may get complaints about leaving C orphaned. > How do I nominate this master to be the one in charge of renews certs and publishing CRLS? I didn't found the procedure. http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > Also do I care to differentiate between the first master and other replica, if my IPA installation use an external root CA certificate (Windows AD in that case)? All masters are equal in IPA with the exception of optional services (CA, DNS) and which one generates the CRL and is the initiator of certificate renewal. rob From nicolas.zin at savoirfairelinux.com Tue Nov 25 21:29:52 2014 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Tue, 25 Nov 2014 16:29:52 -0500 (EST) Subject: [Freeipa-users] Centos5 - freeipa - AD trust In-Reply-To: <240370266.450539.1416950696667.JavaMail.root@mail> Message-ID: <436092240.450946.1416950992482.JavaMail.root@mail> Hi, I successfully create a trust relationship between a freeipa 3.3 realm (on Centos 7) and a windows 2008 AD. Now I add some machine clients to my IPA realm, and try to connect to them with my AD credential: - connecting to the 2 freeipa server: no problem - connecting to a Centos6 machine: no problem - connecting to a Centos5 machine: fail to say it differently: - when connecting to the Centos5 with a Freeipa Realm user it works - when connecting to the Centos5 with a AD Realm user, it fails I just want a confirmation: it fails because centos5 is packaged with sssd < 1.9 and do not support cross realm? (and indeed, it cannot works) or is it possible to make it working? and my error is somewhere else? Regards, Nicolas Zin nicolas.zin at savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From abokovoy at redhat.com Tue Nov 25 21:40:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 23:40:57 +0200 Subject: [Freeipa-users] Centos5 - freeipa - AD trust In-Reply-To: <436092240.450946.1416950992482.JavaMail.root@mail> References: <240370266.450539.1416950696667.JavaMail.root@mail> <436092240.450946.1416950992482.JavaMail.root@mail> Message-ID: <20141125214057.GW28400@redhat.com> On Tue, 25 Nov 2014, Nicolas Zin wrote: >Hi, > >I successfully create a trust relationship between a freeipa 3.3 realm (on Centos 7) and a windows 2008 AD. >Now I add some machine clients to my IPA realm, and try to connect to them with my AD credential: >- connecting to the 2 freeipa server: no problem >- connecting to a Centos6 machine: no problem >- connecting to a Centos5 machine: fail > >to say it differently: >- when connecting to the Centos5 with a Freeipa Realm user it works >- when connecting to the Centos5 with a AD Realm user, it fails > >I just want a confirmation: it fails because centos5 is packaged with >sssd < 1.9 and do not support cross realm? (and indeed, it cannot >works) or is it possible to make it working? and my error is somewhere >else? Right, RHEL5/CentOS5 cannot see AD users directly like other SSSD systems. If you enabled compat tree integration when running 'ipa-adtrust-install', you may try to configure CentOS5 machine to use compat tree. This has some limitations but it exposes both IPA and AD users and allows to authenticate AD users against LDAP in compat tree. See http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf for details. -- / Alexander Bokovoy From rmeggins at redhat.com Tue Nov 25 22:16:32 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Nov 2014 15:16:32 -0700 Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade In-Reply-To: References: <545C602B.90802@redhat.com> <545D2B79.7000200@redhat.com> <546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com> <546DFF77.7090104@redhat.com> <546F193B.4020602@redhat.com> <546F5EF0.2020608@redhat.com> Message-ID: <5474FFC0.7030906@redhat.com> On 11/25/2014 12:32 PM, dbischof at hrz.uni-kassel.de wrote: > Hi, > > with the help of Thierry and Rich I managed to debug the running > ns-slapd on Server1 (see below). The failing attempt of decoding the > SASL data returns a not very fruitful "-1" (SASL_FAIL, "generic > failure"). > > Any ideas? Short summary: > > Server1 = running IPA server > Server2 = intended IPA replica > > Both machines run the exact same, up-to-date version of CentOS 6.6. > However: I had to run "ipa-replica-install" _without_ the option > "--setup-ca" (didn't work, installation failed with some obscure Perl > error), so there's no ns-slapd instance running for PKI-IPA. May this > be related? Are you asking if not having --setup-ca would cause "sasl_io_recv failed to decode packet for connection 2980"? Not that I know of. At this point, it's going to take more than a trivial amount of high latency back-and-forth on the mailling lists. I think we have probably run out of log levels for you to try. Please open a ticket against IPA. While this may turn out to be a bug in 389, at the moment it is only reproducible in your IPA environment. The fastest way to get to the bottom of this problem would be for a 389 developer to run an interactive gdb session on your production machine and poke around. That is, allow one of us to ssh into the machine and run gdb (which will kill the performance and cause outages unless this machine can be taken out of rotation somehow). What would we be looking for? I don't know, but hopefully we would know it when we see it. > > On Fri, 21 Nov 2014, Rich Megginson wrote: > >> On 11/21/2014 04:51 AM, thierry bordaz wrote: >>> On 11/21/2014 10:59 AM, dbischof at hrz.uni-kassel.de wrote: >>>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>>>> On 11/20/2014 12:03 PM, dbischof at hrz.uni-kassel.de wrote: >>>>>> On Thu, 20 Nov 2014, thierry bordaz wrote: >>>>>> >>>>>>> Server1 successfully replicated to Server2, but Server2 fails to >>>>>>> replicated to Server1. >>>>>>> >>>>>>> The replication Server2->Server1 is done with kerberos >>>>>>> authentication. Server1 receives the replication session, >>>>>>> successfully identify the replication manager, start to receives >>>>>>> replication extop but suddenly closes the connection. >>>>>>> >>>>>>> >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 >>>>>>> connection from >>>>>>> xxx to yyy >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn="" >>>>>>> method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn="" >>>>>>> method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn="" >>>>>>> method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 >>>>>>> nentries=0 etime=0 dn="krbprincipalname=xxx" >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base="" scope=0 >>>>>>> filter="(objectClass=*)" attrs="supportedControl >>>>>>> supportedExtension" >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 >>>>>>> nentries=1 etime=0 >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base="" scope=0 >>>>>>> filter="(objectClass=*)" attrs="supportedControl >>>>>>> supportedExtension" >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 >>>>>>> nentries=1 etime=0 >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT >>>>>>> oid="2.16.840.1.113730.3.5.12" >>>>>>> name="replication-multimaster-extop" >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 >>>>>>> nentries=0 etime=0 >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base="cn=schema" >>>>>>> scope=0 filter="(objectClass=*)" attrs="nsSchemaCSN" >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 >>>>>>> nentries=1 etime=0 >>>>>>> [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O >>>>>>> function error. >>>>>>> >>>>>>> The reason of this closure is logged in server1 error log. >>>>>>> sasl_decode fails to decode a received PDU. >>>>>>> >>>>>>> [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode >>>>>>> packet >>>>>>> for connection 2980 >>>>>>> >>>>>>> I do not know why it fails but I wonder if the received PDU is >>>>>>> not larger than the maximum configured value. The attribute >>>>>>> nsslapd-maxsasliosize is set to 2Mb by default. Would it be >>>>>>> possible to increase its value (5Mb) to see if it has an impact >>>>>>> >>>>>>> [...] >>>>>> >>>>>> I set nsslapd-maxsasliosize to 6164480 on both machines, but the >>>>>> problem remains. >>>>> >>>>> The sasl-decode fails but the exact returned value is not logged. >>>>> With standard version we may need to attach a debugger and then >>>>> set a conditional breakpoint in sasl-decode just after >>>>> conn->oparams.decode that will fire if result !=0. Now this can >>>>> change the dynamic and possibly prevent the problem to occur >>>>> again. The other option is to use an instrumented version to log >>>>> this value. >>>> >>>> If I understand the mechanism correctly, Server1 needs to have >>>> debug versions of the relevant packages (probably 389-ds-base and >>>> cyrus-sasl) installed in order to track down the problem. >>>> Unfortunately, my Server1 is in production use - if I break it, my >>>> colleagues will grab forks and torches and be after me. A short >>>> downtime would be ok, though. >>>> >>>> Is there something else I could do? >>> >>> Sure I do not want to trigger so much trouble ;-) >>> >>> >>> I think my email was not clear. To go further we would need to know >>> the exact reason why sasl_decode fails. I see two options: >>> >>> * Prepare a debug version, that would report in the error logs the >>> returned valud of sasl_decode (when it fails). Except downtime to >>> install the debug version, it has no impact in production. >>> >>> * Do a debug session (gdb) on Server1. The debug session will >>> install a breakpoint at a specific place, let the server run, >>> catch the sasl_decode failure and note the return code, exit from >>> debugger. >>> When the problem occurs, it happens regularly (each 5 seconds) so >>> we should not have to wait long. >>> That means that debugging Server1 should disturb production for 5 >>> to 10 min. >>> A detailed procedure to do the debug session is required. >>> >> For starters: >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >> >> Since this is IPA you will need debuginfo packages for ipa and >> slapi-nis in addition to the ones for 389. >> >> Take a look at the Debugging Hangs section where it describes how to >> use gdb to get a stack trace. If you can use that gdb command to get >> a stack trace with the full debugging symbols (and if you don't know >> what that means, just post the redacted stack trace somewhere and >> provide us with a link to it), then you should be all ready to do a >> gdb session to reproduce the error and "catch it in the act". > > > Mit freundlichen Gruessen/With best regards, > > --Daniel. From william.muriithi at gmail.com Wed Nov 26 00:39:04 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 25 Nov 2014 19:39:04 -0500 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy In-Reply-To: References: Message-ID: <20141126003904.6041749.3190.9347@gmail.com> Implications of adding above is that SUDO would break if the > hardcoded ipa is not available even if there is another replica somewhere > in the network. Is that correct assumption? > > Is there a better way of doing it that I have missed? > Which version of sssd do you have? sssd >= 1.10 has native ipa suod providers and you don't need to use "sudo_provider = ldap". ---------------------------- Sorry, responding from blackberry which don't seen to indent the question I am responding to. This is sssd version I am using. Certainly newer than 1.10. Do you mind pointing me to the recommended way of handling SUDO now? ? sssd-common-1.11.2-68.el7_0.6.x86_64 sssd-ipa-1.11.2-68.el7_0.6.x86_64 sssd-1.11.2-68.el7_0.6.x86_64 sssd-client-1.11.2-68.el7_0.6.x86_64 sssd-ad-1.11.2-68.el7_0.6.x86_64 sssd-proxy-1.11.2-68.el7_0.6.x86_64 python-sssdconfig-1.11.2-68.el7_0.6.noarch sssd-common-pac-1.11.2-68.el7_0.6.x86_64 sssd-krb5-1.11.2-68.el7_0.6.x86_64 sssd-krb5-common-1.11.2-68.el7_0.6.x86_64 sssd-ldap-1.11.2-68.el7_0.6.x86_64 William From william.muriithi at gmail.com Wed Nov 26 00:49:38 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 25 Nov 2014 19:49:38 -0500 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy In-Reply-To: References: Message-ID: <20141126004938.6041749.74858.9349@gmail.com> ? List more than 1 LDAP sever in you config then. ldap_uri, ldap_backup_uri (string) Specifies the comma-separated list of URIs of the LDAP servers to which SSSD should connect in the order of preference. Refer to the "FAILOVER" section for more information on failover and server redundancy. If neither option is specified, service discovery is enabled. For more information, refer to the "SERVICE DISCOVERY" section. The format of the URI must match the format defined in RFC 2732: ldap[s]://[:port] For explicit IPv6 addresses, must be enclosed in brackets [] example: ldap://[fc00::126:25]:389 ------------------------- Ah, thanks. Now Google is helpful when I try the 'failover' keywords. See it in mailing list but not on docs Thank you. William? On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < william.muriithi at gmail.com> wrote: > Evening, > > After looking at almost all the SUDO documentation I could find, it looks > one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red > hat advice to add in sssd config file. > > ?services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] > sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com > ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com > ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ > tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM > krb5_server = grobi.idm.coe.muc.redhat.com > > The implications ?of adding above is that SUDO would break if the > hardcoded ipa is not available even if there is another replica somewhere > in the network. Is that correct assumption? > > Is there a better way of doing it that I have missed? > > Thanks > > William > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 25 Nov 2014 14:43:28 +1000 From: Fraser Tweedale To: Rob Crittenden Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] curious about monkeysphere Message-ID: <20141125044328.GA8412 at dhcp-40-8.bne.redhat.com> Content-Type: text/plain; charset=utf-8 On Mon, Nov 24, 2014 at 11:04:50AM -0500, Rob Crittenden wrote: > Outback Dingo wrote: > > ??Im curious about monkeysphere http://web.monkeysphere.info/ and how > > it might compare, integrate, enhance freeipa ..... any thoughts, or > > ideas, or is what it does basically already covered via freeipa? > > > > > > There does seem to be a fair bit of overlap with the SSH key > distribituion/validation. > > We attempt CA fetching in a similar way, by using a trusted mechanism to > fetch it. We use Kerberos when available. > > rob > The projects have very different goals - Monkeysphere is web-of-trust whereas FreeIPA uses centralised authentication and a chain-of-trust PKI - so I do not see much scope for direct integration. Rob's point about some of the underlying mechanisms being similar is accurate - a cross-pollination of ideas or implementations could reduce overall effort. Fraser ------------------------------ Message: 3 Date: Tue, 25 Nov 2014 08:07:46 +0100 From: Martin Kosek To: Rolf Nufable , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] Don't know what To do with this (error?? ) Message-ID: <54742AC2.3060002 at redhat.com> Content-Type: text/plain; charset=utf-8 On 11/25/2014 03:07 AM, Rolf Nufable wrote: > Goodmorning > So I've solved my Time error (I think) in my fedora 20, but even though I'm having the correct time and configured the browser for kerberos authentication I still can't log in my admin account in the web UI > is there a work around for this?? Well, you can log in with your user name and password if GSSAPI does not work. Or is that part also not working? If this is the case, I would suggest to: - check that ipa_memcached service is running - check that there are no SELinux errors in audit.log (or just try in SELinux permissive mode) If user+password login works and GSSAPI does not, make sure that after you fixed the time on your FreeIPA server, you also have time synchronized on your machine with the browser - so that there is not time difference bigger that a 1-2 minutes. > plus I can't find any solutions online on this matter, so I'm really confused on why this is happening in my free ipa :< > TIA : ) ------------------------------ Message: 4 Date: Mon, 24 Nov 2014 23:12:23 -0800 From: Rolf Nufable To: Martin Kosek , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] Don't know what To do with this (error?? ) Message-ID: <1416899543.9132.YahooMailAndroidMobile at web161606.mail.bf1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? Sent from Yahoo Mail on Android -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 25 Nov 2014 08:55:04 +0100 From: Martin Kosek To: Rolf Nufable , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] Don't know what To do with this (error?? ) Message-ID: <547435D8.3080400 at redhat.com> Content-Type: text/plain; charset=windows-1252 On 11/25/2014 08:12 AM, Rolf Nufable wrote: > Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? > > Sent from Yahoo Mail on Android Well, you need to have a ticket on your client machine (the one with the browser) to be able to authenticate via Kerberos. You can check that with # klist To get the ticket, you can either run the kinit manually as you said or let SSSD to get it for you as you authenticate/login to your client machine. AFAIK, this is default behavior. Martin ------------------------------ Message: 6 Date: Tue, 25 Nov 2014 07:59:27 +0000 (UTC) From: Rolf Nufable To: Martin Kosek , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] Don't know what To do with this (error?? ) Message-ID: <1156877372.623540.1416902367456.JavaMail.yahoo at jws10635.mail.bf1.yahoo.com> Content-Type: text/plain; charset="utf-8" ohh sorry I didn't said that I was using the freeipa server on this problem, anyway thanks for the replies :) and before? Thanks, really appreciate it :D On Monday, November 24, 2014 11:55 PM, Martin Kosek wrote: On 11/25/2014 08:12 AM, Rolf Nufable wrote: > Well I tried to kinit the admin account and then reboot the server.. then after that it worked, admin account could then log in the ipa web ui.. but does this mean that everytime I want to log in to the UI i need to kinit manually? > > Sent from Yahoo Mail on Android Well, you need to have a ticket on your client machine (the one with the browser) to be able to authenticate via Kerberos. You can check that with # klist To get the ticket, you can either run the kinit manually as you said or let SSSD to get it for you as you authenticate/login to your client machine. AFAIK, this is default behavior. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users End of Freeipa-users Digest, Vol 76, Issue 110 ********************************************** From rolf_16_nufable at yahoo.com Wed Nov 26 04:31:38 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Wed, 26 Nov 2014 04:31:38 +0000 (UTC) Subject: [Freeipa-users] Freeipa Blocking Sites? Message-ID: <1598913026.1153246.1416976298014.JavaMail.yahoo@jws106101.mail.bf1.yahoo.com> Goodmorning Is there a function in freeipa that blocks websites?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Nov 26 05:51:02 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 26 Nov 2014 15:51:02 +1000 Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <1598913026.1153246.1416976298014.JavaMail.yahoo@jws106101.mail.bf1.yahoo.com> References: <1598913026.1153246.1416976298014.JavaMail.yahoo@jws106101.mail.bf1.yahoo.com> Message-ID: <20141126055102.GG8412@dhcp-40-8.bne.redhat.com> On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > Goodmorning > Is there a function in freeipa that blocks websites?? Hi Rolf, FreeIPA does not have this feature. It is a centralised identity management system providing authentication and access control for hosts and services managed by an organisation. HTH, Fraser > -- > 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 From rolf_16_nufable at yahoo.com Wed Nov 26 06:17:03 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Wed, 26 Nov 2014 06:17:03 +0000 (UTC) Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <20141126055102.GG8412@dhcp-40-8.bne.redhat.com> References: <20141126055102.GG8412@dhcp-40-8.bne.redhat.com> Message-ID: <2020107496.1162985.1416982623449.JavaMail.yahoo@jws10636.mail.bf1.yahoo.com> yea I figured this would be the answer , I was just making sure of the features in free ipa because I didn't read the whole documentation, thanks for the reply Sir Fraser :)? On Tuesday, November 25, 2014 9:51 PM, Fraser Tweedale wrote: On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > Goodmorning > Is there a function in freeipa that blocks websites?? Hi Rolf, FreeIPA does not have this feature.? It is a centralised identity management system providing authentication and access control for hosts and services managed by an organisation. HTH, Fraser > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Wed Nov 26 06:31:59 2014 From: outbackdingo at gmail.com (Outback Dingo) Date: Wed, 26 Nov 2014 17:31:59 +1100 Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <20141126055102.GG8412@dhcp-40-8.bne.redhat.com> References: <1598913026.1153246.1416976298014.JavaMail.yahoo@jws106101.mail.bf1.yahoo.com> <20141126055102.GG8412@dhcp-40-8.bne.redhat.com> Message-ID: You probably want like a squid or oops proxy filter if you mean for filtering web traffic..... On Wed, Nov 26, 2014 at 4:51 PM, Fraser Tweedale wrote: > On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > > Goodmorning > > Is there a function in freeipa that blocks websites? > > Hi Rolf, > > FreeIPA does not have this feature. It is a centralised identity > management system providing authentication and access control for > hosts and services managed by an organisation. > > HTH, > > Fraser > > > -- > > 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 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf_16_nufable at yahoo.com Wed Nov 26 06:36:14 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Wed, 26 Nov 2014 06:36:14 +0000 (UTC) Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: References: Message-ID: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> Actually the problem was that I was accessing our site from outside our network now, our domain in the ?network locally is named example.com, and the outside website is also at the domain example.com so I guess what freeipa does is it looks for the website inside our local network..? On Tuesday, November 25, 2014 10:32 PM, Outback Dingo wrote: You probably want like a squid or oops proxy filter if you mean for filtering web traffic..... On Wed, Nov 26, 2014 at 4:51 PM, Fraser Tweedale wrote: On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > Goodmorning > Is there a function in freeipa that blocks websites?? Hi Rolf, FreeIPA does not have this feature.? It is a centralised identity management system providing authentication and access control for hosts and services managed by an organisation. HTH, Fraser > -- > 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 -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclav.adamec at suchy-zleb.cz Wed Nov 26 07:33:07 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Wed, 26 Nov 2014 08:33:07 +0100 Subject: [Freeipa-users] Failed to remove host Message-ID: Hi, I'm encounter strange behavior, I run host removing from web UI and it failed with error "Some entries were not deleted xxxx: host not found" but it's still showing in list. Via cmd: ipa host-find xxxx -------------- 1 host matched -------------- Host name: xxxx Principal name: host/xxxx at xxxx Password: True Member of host-groups: all Indirect Member of netgroup:xxxx Indirect Member of HBAC rule: xxxx Keytab: True ---------------------------- Number of entries returned 1 ipa host-del xxxx ipa: ERROR: xxxx: host not found can you please advice ? Thanks a lot Vasek freeipa-server-4.1.0-1.fc20.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Nov 26 07:58:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Nov 2014 08:58:22 +0100 Subject: [Freeipa-users] Failed to remove host In-Reply-To: References: Message-ID: <5475881E.9060204@redhat.com> On 11/26/2014 08:33 AM, Vaclav Adamec wrote: > Hi, > I'm encounter strange behavior, I run host removing from web UI and it > failed with error "Some entries were not deleted xxxx: host not found" but > it's still showing in list. Via cmd: > > ipa host-find xxxx > > -------------- > 1 host matched > -------------- > Host name: xxxx > Principal name: host/xxxx at xxxx > Password: True > Member of host-groups: all > Indirect Member of netgroup:xxxx > Indirect Member of HBAC rule: xxxx > Keytab: True > ---------------------------- > Number of entries returned 1 > > ipa host-del xxxx > > ipa: ERROR: xxxx: host not found > > > can you please advice ? > > Thanks a lot > > Vasek > > freeipa-server-4.1.0-1.fc20.x86_64 > ipa-client-3.0.0-42.el6.centos.x86_64 Vasku, I suspect there was a replication conflict and this particular host has modified DN. You can verify with # ipa host-find --all --raw | grep "dn:" If this is the case, you can find some hints how to remove replication conflicts here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#repl-conflicts HTH, Martin From vaclav.adamec at suchy-zleb.cz Wed Nov 26 08:37:36 2014 From: vaclav.adamec at suchy-zleb.cz (Vaclav Adamec) Date: Wed, 26 Nov 2014 09:37:36 +0100 Subject: [Freeipa-users] Failed to remove host In-Reply-To: <5475881E.9060204@redhat.com> References: <5475881E.9060204@redhat.com> Message-ID: Thanks, that's it. Not very clear how to fix it (example with uid "converted" to host issue is not working) but at least I known what's wrong Vasek On Wed, Nov 26, 2014 at 8:58 AM, Martin Kosek wrote: > On 11/26/2014 08:33 AM, Vaclav Adamec wrote: > > Hi, > > I'm encounter strange behavior, I run host removing from web UI and it > > failed with error "Some entries were not deleted xxxx: host not found" > but > > it's still showing in list. Via cmd: > > > > ipa host-find xxxx > > > > -------------- > > 1 host matched > > -------------- > > Host name: xxxx > > Principal name: host/xxxx at xxxx > > Password: True > > Member of host-groups: all > > Indirect Member of netgroup:xxxx > > Indirect Member of HBAC rule: xxxx > > Keytab: True > > ---------------------------- > > Number of entries returned 1 > > > > ipa host-del xxxx > > > > ipa: ERROR: xxxx: host not found > > > > > > can you please advice ? > > > > Thanks a lot > > > > Vasek > > > > freeipa-server-4.1.0-1.fc20.x86_64 > > ipa-client-3.0.0-42.el6.centos.x86_64 > > Vasku, > > I suspect there was a replication conflict and this particular host has > modified DN. You can verify with > > # ipa host-find --all --raw | grep "dn:" > > If this is the case, you can find some hints how to remove replication > conflicts here: > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#repl-conflicts > > HTH, > Martin > -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/----\|\ V " " " " -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Wed Nov 26 09:07:41 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 26 Nov 2014 10:07:41 +0100 Subject: [Freeipa-users] Is it possible to set up SUDO with redudancy In-Reply-To: <20141126003904.6041749.3190.9347@gmail.com> References: <20141126003904.6041749.3190.9347@gmail.com> Message-ID: <20141126090740.GC22609@mail.corp.redhat.com> On (25/11/14 19:39), William Muriithi wrote: >Implications of adding above is that SUDO would break if the >> hardcoded ipa is not available even if there is another replica somewhere >> in the network. Is that correct assumption? >> >> Is there a better way of doing it that I have missed? >> > >Which version of sssd do you have? >sssd >= 1.10 has native ipa suod providers and you don't need to use >"sudo_provider = ldap". > >---------------------------- > >Sorry, responding from blackberry which don't seen to indent the question I am responding to. > >This is sssd version I am using. Certainly newer than 1.10. Do you mind pointing me to the recommended way of handling SUDO now? > > >? >sssd-common-1.11.2-68.el7_0.6.x86_64 >sssd-ipa-1.11.2-68.el7_0.6.x86_64 >sssd-1.11.2-68.el7_0.6.x86_64 >sssd-client-1.11.2-68.el7_0.6.x86_64 >sssd-ad-1.11.2-68.el7_0.6.x86_64 >sssd-proxy-1.11.2-68.el7_0.6.x86_64 >python-sssdconfig-1.11.2-68.el7_0.6.noarch >sssd-common-pac-1.11.2-68.el7_0.6.x86_64 >sssd-krb5-1.11.2-68.el7_0.6.x86_64 >sssd-krb5-common-1.11.2-68.el7_0.6.x86_64 >sssd-ldap-1.11.2-68.el7_0.6.x86_64 > > If you call ipa-client-install then sssd.conf needn't be changed. You just need to configure nsswitch.conf. It shoudl contain "sudoers: files sss". NIS domain name should be set corectly as well. Detail description is in manual page: "man sssd-sudo" LS From rolf_16_nufable at yahoo.com Wed Nov 26 10:14:03 2014 From: rolf_16_nufable at yahoo.com (Rolf Nufable) Date: Wed, 26 Nov 2014 10:14:03 +0000 (UTC) Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> References: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> Message-ID: <645693265.1262287.1416996843288.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> I have a stupid question (LOL) should or can ?freeIpa Have internet connection?? On Tuesday, November 25, 2014 10:36 PM, Rolf Nufable wrote: Actually the problem was that I was accessing our site from outside our network now, our domain in the ?network locally is named example.com, and the outside website is also at the domain example.com so I guess what freeipa does is it looks for the website inside our local network..? On Tuesday, November 25, 2014 10:32 PM, Outback Dingo wrote: You probably want like a squid or oops proxy filter if you mean for filtering web traffic..... On Wed, Nov 26, 2014 at 4:51 PM, Fraser Tweedale wrote: On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > Goodmorning > Is there a function in freeipa that blocks websites?? Hi Rolf, FreeIPA does not have this feature.? It is a centralised identity management system providing authentication and access control for hosts and services managed by an organisation. HTH, Fraser > -- > 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 -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From emteeoh at gmail.com Wed Nov 26 15:28:00 2014 From: emteeoh at gmail.com (Richard Betel) Date: Wed, 26 Nov 2014 10:28:00 -0500 Subject: [Freeipa-users] scripting question Message-ID: I'm trying to debug a script that is supposed to auto-setup kerberos for Hadoop. Its not working, and I've boiled down the problem to the fact that for some reason, it wants to use DES as the encryption type. There is no good reason for this, since both freeIPA and Hadoop support modern encryptions, so I want to fix the script. Is there a way for a script to query IPA for the supported encryption types? -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 26 15:54:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Nov 2014 10:54:24 -0500 Subject: [Freeipa-users] scripting question In-Reply-To: References: Message-ID: <5475F7B0.6080200@redhat.com> Richard Betel wrote: > I'm trying to debug a script that is supposed to auto-setup kerberos for > Hadoop. Its not working, and I've boiled down the problem to the fact > that for some reason, it wants to use DES as the encryption type. There > is no good reason for this, since both freeIPA and Hadoop support modern > encryptions, so I want to fix the script. Is there a way for a script to > query IPA for the supported encryption types? > You can find it in cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com $ ldapsearch -Y GSSAPI -s base -b cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com krbDefaultEncSaltTypes rob From dpal at redhat.com Wed Nov 26 16:18:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Nov 2014 11:18:25 -0500 Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> References: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> Message-ID: <5475FD51.4080505@redhat.com> On 11/26/2014 01:36 AM, Rolf Nufable wrote: > Actually the problem was that I was accessing our site from outside > our network now, our domain in the network locally is named > example.com, and the outside website is also at the domain example.com > so I guess what freeipa does is it looks for the website inside our > local network.. > I looks for a name and DNS resolves it. So if DNS resolved to the internal one then the internal will be used. If there is a route to the external and DNS returned is then it will be external. It is really not IPA's capability we are talking about here. > > On Tuesday, November 25, 2014 10:32 PM, Outback Dingo > wrote: > > > You probably want like a squid or oops proxy filter if you mean for > filtering web traffic..... > > On Wed, Nov 26, 2014 at 4:51 PM, Fraser Tweedale > wrote: > > On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > > Goodmorning > > Is there a function in freeipa that blocks websites? > > Hi Rolf, > > FreeIPA does not have this feature. It is a centralised identity > management system providing authentication and access control for > hosts and services managed by an organisation. > > HTH, > > Fraser > > > -- > > 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 > > > -- > 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 > > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Nov 26 16:20:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Nov 2014 11:20:16 -0500 Subject: [Freeipa-users] Freeipa Blocking Sites? In-Reply-To: <645693265.1262287.1416996843288.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> References: <1685119086.1155239.1416983774791.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com> <645693265.1262287.1416996843288.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Message-ID: <5475FDC0.6080200@redhat.com> On 11/26/2014 05:14 AM, Rolf Nufable wrote: > I have a stupid question (LOL) > > should or can freeIpa Have internet connection? It depends on the needs. Usually it is hidden behind the Firewall internally but there are some cases when it makes sense to run it on the Internet. What is the problem you are trying to solve? > > > On Tuesday, November 25, 2014 10:36 PM, Rolf Nufable > wrote: > > > Actually the problem was that I was accessing our site from outside > our network now, our domain in the network locally is named > example.com, and the outside website is also at the domain example.com > so I guess what freeipa does is it looks for the website inside our > local network.. > > > On Tuesday, November 25, 2014 10:32 PM, Outback Dingo > wrote: > > > You probably want like a squid or oops proxy filter if you mean for > filtering web traffic..... > > On Wed, Nov 26, 2014 at 4:51 PM, Fraser Tweedale > wrote: > > On Wed, Nov 26, 2014 at 04:31:38AM +0000, Rolf Nufable wrote: > > Goodmorning > > Is there a function in freeipa that blocks websites? > > Hi Rolf, > > FreeIPA does not have this feature. It is a centralised identity > management system providing authentication and access control for > hosts and services managed by an organisation. > > HTH, > > Fraser > > > -- > > 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 > > > -- > 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 > > > > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 26 17:04:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 18:04:21 +0100 Subject: [Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY In-Reply-To: References: Message-ID: <54760815.4030407@redhat.com> Hello, Simo, do you have an idea what may be causing the problem? Maria, generally, you can try to do two things on Zimbra server: $ kinit -kt "imap/zimbrafreeipa.example.com at FI.example.com" It should succeed. This will very that content of the keytab is okay. Regarding KRB5_TRACE trick: You have to find init script or systemd unit file which is used to start Zimbra server process. Edit that script and add KRB5_TRACE to it before the actual server start. Let us know your findings :-) Petr^2 Spacek On 25.11.2014 19:02, Maria Jose Ya?ez Dacosta wrote: > Sorry for delay in answering, I've been testing a few things before going > back to ask. > > Thanks for the advice, I'll be careful with security :). > > I also tried as is explained in the url you shared with me and as you > suspected that isn't the problem either. > > I installed Wireshark, packet capture shows me these errors: > > error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) > e-text: PREAUTH_FAILED > > Where the origin of these packages is the FreeIPA server and the > destination is the Zimbra server. > > I think this may be causing problems. > > I'm ashamed to say this, but haven't known as I have to do to debug Imap > process on the server using KRB5_TRACE. > > Thanks so much for all your help and if you have more suggestions, it would > be appreciated. > > Have a good day. > > > > > 2014-11-25 15:00 GMT-02:00 : > >> Send Freeipa-users mailing list submissions to >> freeipa-users at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/freeipa-users >> or, via email, send a message with subject or body 'help' to >> freeipa-users-request at redhat.com >> >> You can reach the person managing the list at >> freeipa-users-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freeipa-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Is it possible to set up SUDO with redudancy? >> (Lukas Slebodnik) >> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 Nov 2014 09:02:59 +0100 >> From: Lukas Slebodnik >> To: William Muriithi >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with >> redudancy? >> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> >> Content-Type: text/plain; charset=utf-8 >> >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < >> william.muriithi at gmail.com> wrote: >> >>> Evening, >>> >>> After looking at almost all the SUDO documentation I could find, it looks >>> one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red >>> hat advice to add in sssd config file. >>> >>> services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] >>> sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com >>> ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com >>> ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ >>> tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM >>> krb5_server = grobi.idm.coe.muc.redhat.com >>> >>> The implications of adding above is that SUDO would break if the >>> hardcoded ipa is not available even if there is another replica somewhere >>> in the network. Is that correct assumption? >>> >>> Is there a better way of doing it that I have missed? >>> >> >> Which version of sssd do you have? >> sssd >= 1.10 has native ipa suod providers and you don't need to use >> "sudo_provider = ldap". >> >> LS >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 25 Nov 2014 10:11:42 +0100 >> From: Petr Spacek >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. >> Message-ID: <547447CE.8090400 at redhat.com> >> Content-Type: text/plain; charset=windows-1252 >> >> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: >>> Thank you for your prompt reply :). >>> >>> I still don't discover what caused the problem, but now I could get more >>> information about the problem. >>> >>> I run the command that you commented me, I did as follows: >>> >>> - kinit usuipa >>> - kvno imap/zimbrafreeipa.example.com at FI.example.com >>> >>> (I said in my previous mail fi.example.com but should have said >>> zimbrafreeipa.example.com. >>> Forgiveness!!). >>> >>> Then run klist and got this: >>> >>> 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ >> FI.EXAMPLE.COM at FI.EXAMPLE.COM >>> 11/24/14 14:05:52 11/25/14 14:04:50 imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>> >>> Then run >>> KRB5_TRACE=/dev/stdout kvno imap/ >> zimbrafreeipa.example.com at FI.EXAMPLE.COM >>> and got this: >>> --------------------------------------- OUTPUT >>> --------------------------------------------------------------- >>> [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> >> imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >> FILE:/tmp/krb5cc_0 >>> [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 >>> --------------------------------------- END OF OUTPUT >>> --------------------------------------------------- >>> >>> When I rum >>> KRB5_TRACE=/dev/stdout thunderbird >>> this show: >>> >>> --------------------------------------- OUTPUT >>> --------------------------------------------------------------- >>> Gtk-Message: Failed to load module "canberra-gtk-module": >>> libcanberra-gtk-module.so: no se puede abrir el fichero del objeto >>> compartido: No existe el fichero o el directorio >>> [20906] 1416845377.323420: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>> [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >>> FILE:/tmp/krb5cc_0 >>> [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> [20906] 1416845377.325617: Creating authenticator for >> usuipa at FI.EXAMPLE.COM >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, >>> subkey aes256-cts/3BB4, session key aes256-cts/A007 >>> [20906] 1416845377.353847: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>> [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey >>> (null), seqnum 1067232298 >>> [20906] 1416845396.10173: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>> [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> >> imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >> FILE:/tmp/krb5cc_0 >>> [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> [20906] 1416845396.10469: Creating authenticator for >> usuipa at FI.EXAMPLE.COM >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, >>> subkey aes256-cts/5F4D, session key aes256-cts/A007 >>> [20906] 1416845396.35033: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>> [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey >>> (null), seqnum 911725412 >>> >>> --------------------------------------- END OF OUTPUT >>> --------------------------------------------------- >> >> This seems okay, Thunderbird got necessary ticket so the problem could be >> on >> server side. (Just to be 100% sure: Did you configure >> network.negotiate-auth >> option in Thunderbird according to >> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) >> >>> About permissions on keytab file, I have as following: >>> >>> ls -l /opt/zimbra/conf/krb5.keytab >>> -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab >>> >>> Selinux (/etc/selinux/config) >>> SELINUX=disabled >>> >>> What do you think about this?, >> >> That it is completely insecure :-) Seriously, keytab contains symmetric >> cryptographic keys so it should be protected as much as feasible. >> >> It is fine for testing purposes (assuming that you do not forget to secure >> file permissions and generate new keytab before moving it to production). >> >> As a next step please raise debug levels on the server and possibly use >> KRB5_TRACE=/dev/stdout trick for IMAP server process. >> >> -- >> Petr^2 Spacek From sbose at redhat.com Wed Nov 26 17:45:14 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 26 Nov 2014 18:45:14 +0100 Subject: [Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY In-Reply-To: <54760815.4030407@redhat.com> References: <54760815.4030407@redhat.com> Message-ID: <20141126174514.GG27699@localhost.localdomain> On Wed, Nov 26, 2014 at 06:04:21PM +0100, Petr Spacek wrote: > Hello, > > Simo, do you have an idea what may be causing the problem? Maybe there is a version mismatch between the keys on the server and on the client? On the IPA server you can check with #kadmin.local > getprinc imap/zimbrafreeipa.example.com at FI.example.com on the IMAP server klist -k -t the KVNO should be the same, if not you can generate a fresh keytab with ipa-getkeytab. hth bye, Sumit > > Maria, generally, you can try to do two things on Zimbra server: > $ kinit -kt > "imap/zimbrafreeipa.example.com at FI.example.com" > > It should succeed. This will very that content of the keytab is okay. > > Regarding KRB5_TRACE trick: > You have to find init script or systemd unit file which is used to start > Zimbra server process. Edit that script and add KRB5_TRACE to it before the > actual server start. > > Let us know your findings :-) > > Petr^2 Spacek > > On 25.11.2014 19:02, Maria Jose Ya?ez Dacosta wrote: > > Sorry for delay in answering, I've been testing a few things before going > > back to ask. > > > > Thanks for the advice, I'll be careful with security :). > > > > I also tried as is explained in the url you shared with me and as you > > suspected that isn't the problem either. > > > > I installed Wireshark, packet capture shows me these errors: > > > > error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) > > e-text: PREAUTH_FAILED > > > > Where the origin of these packages is the FreeIPA server and the > > destination is the Zimbra server. > > > > I think this may be causing problems. > > > > I'm ashamed to say this, but haven't known as I have to do to debug Imap > > process on the server using KRB5_TRACE. > > > > Thanks so much for all your help and if you have more suggestions, it would > > be appreciated. > > > > Have a good day. > > > > > > > > > > 2014-11-25 15:00 GMT-02:00 : > > > >> Send Freeipa-users mailing list submissions to > >> freeipa-users at redhat.com > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> or, via email, send a message with subject or body 'help' to > >> freeipa-users-request at redhat.com > >> > >> You can reach the person managing the list at > >> freeipa-users-owner at redhat.com > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of Freeipa-users digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: Is it possible to set up SUDO with redudancy? > >> (Lukas Slebodnik) > >> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 25 Nov 2014 09:02:59 +0100 > >> From: Lukas Slebodnik > >> To: William Muriithi > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with > >> redudancy? > >> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> > >> Content-Type: text/plain; charset=utf-8 > >> > >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < > >> william.muriithi at gmail.com> wrote: > >> > >>> Evening, > >>> > >>> After looking at almost all the SUDO documentation I could find, it looks > >>> one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red > >>> hat advice to add in sssd config file. > >>> > >>> services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] > >>> sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com > >>> ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com > >>> ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ > >>> tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM > >>> krb5_server = grobi.idm.coe.muc.redhat.com > >>> > >>> The implications of adding above is that SUDO would break if the > >>> hardcoded ipa is not available even if there is another replica somewhere > >>> in the network. Is that correct assumption? > >>> > >>> Is there a better way of doing it that I have missed? > >>> > >> > >> Which version of sssd do you have? > >> sssd >= 1.10 has native ipa suod providers and you don't need to use > >> "sudo_provider = ldap". > >> > >> LS > >> > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Tue, 25 Nov 2014 10:11:42 +0100 > >> From: Petr Spacek > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. > >> Message-ID: <547447CE.8090400 at redhat.com> > >> Content-Type: text/plain; charset=windows-1252 > >> > >> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: > >>> Thank you for your prompt reply :). > >>> > >>> I still don't discover what caused the problem, but now I could get more > >>> information about the problem. > >>> > >>> I run the command that you commented me, I did as follows: > >>> > >>> - kinit usuipa > >>> - kvno imap/zimbrafreeipa.example.com at FI.example.com > >>> > >>> (I said in my previous mail fi.example.com but should have said > >>> zimbrafreeipa.example.com. > >>> Forgiveness!!). > >>> > >>> Then run klist and got this: > >>> > >>> 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ > >> FI.EXAMPLE.COM at FI.EXAMPLE.COM > >>> 11/24/14 14:05:52 11/25/14 14:04:50 imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> > >>> Then run > >>> KRB5_TRACE=/dev/stdout kvno imap/ > >> zimbrafreeipa.example.com at FI.EXAMPLE.COM > >>> and got this: > >>> --------------------------------------- OUTPUT > >>> --------------------------------------------------------------- > >>> [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> > >> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >> FILE:/tmp/krb5cc_0 > >>> [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > >>> result: 0/Conseguido > >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 > >>> --------------------------------------- END OF OUTPUT > >>> --------------------------------------------------- > >>> > >>> When I rum > >>> KRB5_TRACE=/dev/stdout thunderbird > >>> this show: > >>> > >>> --------------------------------------- OUTPUT > >>> --------------------------------------------------------------- > >>> Gtk-Message: Failed to load module "canberra-gtk-module": > >>> libcanberra-gtk-module.so: no se puede abrir el fichero del objeto > >>> compartido: No existe el fichero o el directorio > >>> [20906] 1416845377.323420: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > >>> [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> > >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >>> FILE:/tmp/krb5cc_0 > >>> [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > >>> result: 0/Conseguido > >>> [20906] 1416845377.325617: Creating authenticator for > >> usuipa at FI.EXAMPLE.COM > >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, > >>> subkey aes256-cts/3BB4, session key aes256-cts/A007 > >>> [20906] 1416845377.353847: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > >>> [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey > >>> (null), seqnum 1067232298 > >>> [20906] 1416845396.10173: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > >>> [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> > >> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >> FILE:/tmp/krb5cc_0 > >>> [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with > >>> result: 0/Conseguido > >>> [20906] 1416845396.10469: Creating authenticator for > >> usuipa at FI.EXAMPLE.COM > >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, > >>> subkey aes256-cts/5F4D, session key aes256-cts/A007 > >>> [20906] 1416845396.35033: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found > >>> [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey > >>> (null), seqnum 911725412 > >>> > >>> --------------------------------------- END OF OUTPUT > >>> --------------------------------------------------- > >> > >> This seems okay, Thunderbird got necessary ticket so the problem could be > >> on > >> server side. (Just to be 100% sure: Did you configure > >> network.negotiate-auth > >> option in Thunderbird according to > >> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) > >> > >>> About permissions on keytab file, I have as following: > >>> > >>> ls -l /opt/zimbra/conf/krb5.keytab > >>> -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab > >>> > >>> Selinux (/etc/selinux/config) > >>> SELINUX=disabled > >>> > >>> What do you think about this?, > >> > >> That it is completely insecure :-) Seriously, keytab contains symmetric > >> cryptographic keys so it should be protected as much as feasible. > >> > >> It is fine for testing purposes (assuming that you do not forget to secure > >> file permissions and generate new keytab before moving it to production). > >> > >> As a next step please raise debug levels on the server and possibly use > >> KRB5_TRACE=/dev/stdout trick for IMAP server process. > >> > >> -- > >> 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 From nicolas.zin at savoirfairelinux.com Wed Nov 26 17:50:15 2014 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Wed, 26 Nov 2014 12:50:15 -0500 (EST) Subject: [Freeipa-users] Centos5 - freeipa - AD trust In-Reply-To: <20141125214057.GW28400@redhat.com> Message-ID: <552138644.163494.1417024215200.JavaMail.root@mail> Thank you, it works like a charm, especially the ipa-advise. One last question: is there a way to login on the centos5 without entering the whole realm name, but just the netbios. Currently I can log on centos6 with "\", but on centos5 I need to provide ssh ipaCentos5 -l @ I don't have tested yet with putty, from windows, maybe it doesn't matter. Regards, Nicolas Zin ----- Mail original ----- De: "Alexander Bokovoy" ?: "Nicolas Zin" Cc: freeipa-users at redhat.com Envoy?: Mardi 25 Novembre 2014 16:40:57 Objet: Re: [Freeipa-users] Centos5 - freeipa - AD trust On Tue, 25 Nov 2014, Nicolas Zin wrote: >Hi, > >I successfully create a trust relationship between a freeipa 3.3 realm (on Centos 7) and a windows 2008 AD. >Now I add some machine clients to my IPA realm, and try to connect to them with my AD credential: >- connecting to the 2 freeipa server: no problem >- connecting to a Centos6 machine: no problem >- connecting to a Centos5 machine: fail > >to say it differently: >- when connecting to the Centos5 with a Freeipa Realm user it works >- when connecting to the Centos5 with a AD Realm user, it fails > >I just want a confirmation: it fails because centos5 is packaged with >sssd < 1.9 and do not support cross realm? (and indeed, it cannot >works) or is it possible to make it working? and my error is somewhere >else? Right, RHEL5/CentOS5 cannot see AD users directly like other SSSD systems. If you enabled compat tree integration when running 'ipa-adtrust-install', you may try to configure CentOS5 machine to use compat tree. This has some limitations but it exposes both IPA and AD users and allows to authenticate AD users against LDAP in compat tree. See http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf for details. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Nov 26 17:55:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Nov 2014 19:55:00 +0200 Subject: [Freeipa-users] Centos5 - freeipa - AD trust In-Reply-To: <552138644.163494.1417024215200.JavaMail.root@mail> References: <20141125214057.GW28400@redhat.com> <552138644.163494.1417024215200.JavaMail.root@mail> Message-ID: <20141126175500.GB28400@redhat.com> On Wed, 26 Nov 2014, Nicolas Zin wrote: >Thank you, > >it works like a charm, especially the ipa-advise. > >One last question: is there a way to login on the centos5 without >entering the whole realm name, but just the netbios. Currently I can >log on centos6 with "\", but on centos5 I need to >provide ssh ipaCentos5 -l @ >I don't have tested yet with putty, from windows, maybe it doesn't matter. Not supported yet in slapi-nis, good finding. You can file a ticket at https://fedorahosted.org/slapi-nis/ so that it wouldn't be lost. -- / Alexander Bokovoy From simo at redhat.com Wed Nov 26 20:05:16 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Nov 2014 15:05:16 -0500 Subject: [Freeipa-users] scripting question In-Reply-To: References: Message-ID: <20141126150516.1f7c8888@willson.usersys.redhat.com> On Wed, 26 Nov 2014 10:28:00 -0500 Richard Betel wrote: > I'm trying to debug a script that is supposed to auto-setup kerberos > for Hadoop. Its not working, and I've boiled down the problem to the > fact that for some reason, it wants to use DES as the encryption > type. There is no good reason for this, since both freeIPA and Hadoop > support modern encryptions, so I want to fix the script. Is there a > way for a script to query IPA for the supported encryption types? Why don't you just go with the defaults ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Nov 26 20:28:47 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Nov 2014 15:28:47 -0500 Subject: [Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY In-Reply-To: <54760815.4030407@redhat.com> References: <54760815.4030407@redhat.com> Message-ID: <20141126152847.17df885a@willson.usersys.redhat.com> On Wed, 26 Nov 2014 18:04:21 +0100 Petr Spacek wrote: > Hello, > > Simo, do you have an idea what may be causing the problem? The most probable explanation is that the Zimbra server has the wrong key. Unfortuinately there isn't enough data in the email to guess further. Simo. > Maria, generally, you can try to do two things on Zimbra server: > $ kinit -kt > "imap/zimbrafreeipa.example.com at FI.example.com" > > It should succeed. This will very that content of the keytab is okay. > > Regarding KRB5_TRACE trick: > You have to find init script or systemd unit file which is used to > start Zimbra server process. Edit that script and add KRB5_TRACE to > it before the actual server start. > > Let us know your findings :-) > > Petr^2 Spacek > > On 25.11.2014 19:02, Maria Jose Ya?ez Dacosta wrote: > > Sorry for delay in answering, I've been testing a few things before > > going back to ask. > > > > Thanks for the advice, I'll be careful with security :). > > > > I also tried as is explained in the url you shared with me and as > > you suspected that isn't the problem either. > > > > I installed Wireshark, packet capture shows me these errors: > > > > error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) > > e-text: PREAUTH_FAILED > > > > Where the origin of these packages is the FreeIPA server and the > > destination is the Zimbra server. > > > > I think this may be causing problems. > > > > I'm ashamed to say this, but haven't known as I have to do to debug > > Imap process on the server using KRB5_TRACE. > > > > Thanks so much for all your help and if you have more suggestions, > > it would be appreciated. > > > > Have a good day. > > > > > > > > > > 2014-11-25 15:00 GMT-02:00 : > > > >> Send Freeipa-users mailing list submissions to > >> freeipa-users at redhat.com > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> or, via email, send a message with subject or body 'help' to > >> freeipa-users-request at redhat.com > >> > >> You can reach the person managing the list at > >> freeipa-users-owner at redhat.com > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of Freeipa-users digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: Is it possible to set up SUDO with redudancy? > >> (Lukas Slebodnik) > >> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 25 Nov 2014 09:02:59 +0100 > >> From: Lukas Slebodnik > >> To: William Muriithi > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with > >> redudancy? > >> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> > >> Content-Type: text/plain; charset=utf-8 > >> > >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < > >> william.muriithi at gmail.com> wrote: > >> > >>> Evening, > >>> > >>> After looking at almost all the SUDO documentation I could find, > >>> it looks one has to hardcode FreeIPA hostname on sssd.conf file. > >>> Below is what red hat advice to add in sssd config file. > >>> > >>> services = nss, pam, ssh, pac, sudo > >>> [domain/idm.coe.muc.redhat.com] sudo_provider = ldap ldap_uri = > >>> ldap://grobi.idm.coe.muc.redhat.com ldap_sudo_search_base = > >>> ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com ldap_sasl_mech = > >>> GSSAPI ldap_sasl_authid = host/ tiffy.idm.coe.muc.redhat.com > >>> ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM krb5_server = > >>> grobi.idm.coe.muc.redhat.com > >>> > >>> The implications of adding above is that SUDO would break if the > >>> hardcoded ipa is not available even if there is another replica > >>> somewhere in the network. Is that correct assumption? > >>> > >>> Is there a better way of doing it that I have missed? > >>> > >> > >> Which version of sssd do you have? > >> sssd >= 1.10 has native ipa suod providers and you don't need to > >> use "sudo_provider = ldap". > >> > >> LS > >> > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Tue, 25 Nov 2014 10:11:42 +0100 > >> From: Petr Spacek > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. > >> Message-ID: <547447CE.8090400 at redhat.com> > >> Content-Type: text/plain; charset=windows-1252 > >> > >> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: > >>> Thank you for your prompt reply :). > >>> > >>> I still don't discover what caused the problem, but now I could > >>> get more information about the problem. > >>> > >>> I run the command that you commented me, I did as follows: > >>> > >>> - kinit usuipa > >>> - kvno imap/zimbrafreeipa.example.com at FI.example.com > >>> > >>> (I said in my previous mail fi.example.com but should have said > >>> zimbrafreeipa.example.com. > >>> Forgiveness!!). > >>> > >>> Then run klist and got this: > >>> > >>> 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ > >> FI.EXAMPLE.COM at FI.EXAMPLE.COM > >>> 11/24/14 14:05:52 11/25/14 14:04:50 imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> > >>> Then run > >>> KRB5_TRACE=/dev/stdout kvno imap/ > >> zimbrafreeipa.example.com at FI.EXAMPLE.COM > >>> and got this: > >>> --------------------------------------- OUTPUT > >>> --------------------------------------------------------------- > >>> [20649] 1416845334.9690: Getting credentials > >>> usuipa at FI.EXAMPLE.COM -> > >> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >> FILE:/tmp/krb5cc_0 > >>> [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from > >>> FILE:/tmp/krb5cc_0 with result: 0/Conseguido > >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 > >>> --------------------------------------- END OF OUTPUT > >>> --------------------------------------------------- > >>> > >>> When I rum > >>> KRB5_TRACE=/dev/stdout thunderbird > >>> this show: > >>> > >>> --------------------------------------- OUTPUT > >>> --------------------------------------------------------------- > >>> Gtk-Message: Failed to load module "canberra-gtk-module": > >>> libcanberra-gtk-module.so: no se puede abrir el fichero del objeto > >>> compartido: No existe el fichero o el directorio > >>> [20906] 1416845377.323420: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential > >>> not found [20906] 1416845377.323939: Getting credentials > >>> usuipa at FI.EXAMPLE.COM -> > >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >>> FILE:/tmp/krb5cc_0 [20906] 1416845377.324677: Retrieving > >>> usuipa at FI.EXAMPLE.COM -> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from > >>> FILE:/tmp/krb5cc_0 with result: 0/Conseguido [20906] > >>> 1416845377.325617: Creating authenticator for > >> usuipa at FI.EXAMPLE.COM > >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum > >>> 138355536, subkey aes256-cts/3BB4, session key aes256-cts/A007 > >>> [20906] 1416845377.353847: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential > >>> not found [20906] 1416845377.354331: Read AP-REP, time > >>> 1416845380.325675, subkey (null), seqnum 1067232298 > >>> [20906] 1416845396.10173: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential > >>> not found [20906] 1416845396.10316: Getting credentials > >>> usuipa at FI.EXAMPLE.COM -> > >> imap/ > >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache > >> FILE:/tmp/krb5cc_0 > >>> [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> imap/ zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from > >>> FILE:/tmp/krb5cc_0 with result: 0/Conseguido > >>> [20906] 1416845396.10469: Creating authenticator for > >> usuipa at FI.EXAMPLE.COM > >>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum > >>> 592157704, subkey aes256-cts/5F4D, session key aes256-cts/A007 > >>> [20906] 1416845396.35033: ccselect module realm chose cache > >>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for > >> server > >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM > >>> [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> > >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from > >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential > >>> not found [20906] 1416845396.35293: Read AP-REP, time > >>> 1416845399.10477, subkey (null), seqnum 911725412 > >>> > >>> --------------------------------------- END OF OUTPUT > >>> --------------------------------------------------- > >> > >> This seems okay, Thunderbird got necessary ticket so the problem > >> could be on > >> server side. (Just to be 100% sure: Did you configure > >> network.negotiate-auth > >> option in Thunderbird according to > >> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) > >> > >>> About permissions on keytab file, I have as following: > >>> > >>> ls -l /opt/zimbra/conf/krb5.keytab > >>> -rwxrwxrwx 1 zimbra zimbra 366 nov 20 > >>> 14:45 /opt/zimbra/conf/krb5.keytab > >>> > >>> Selinux (/etc/selinux/config) > >>> SELINUX=disabled > >>> > >>> What do you think about this?, > >> > >> That it is completely insecure :-) Seriously, keytab contains > >> symmetric cryptographic keys so it should be protected as much as > >> feasible. > >> > >> It is fine for testing purposes (assuming that you do not forget > >> to secure file permissions and generate new keytab before moving > >> it to production). > >> > >> As a next step please raise debug levels on the server and > >> possibly use KRB5_TRACE=/dev/stdout trick for IMAP server process. > >> > >> -- > >> Petr^2 Spacek -- Simo Sorce * Red Hat, Inc * New York From mitkany at gmail.com Wed Nov 26 22:41:06 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Wed, 26 Nov 2014 17:41:06 -0500 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <20141125203235.GV28400@redhat.com> References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> <20140929171206.3eb8e5f7@willson.usersys.redhat.com> <542A5564.4070205@redhat.com> <20141125203235.GV28400@redhat.com> Message-ID: Thanks Alexander. Reviewing the proxy requirements now. On Tue, Nov 25, 2014 at 3:32 PM, Alexander Bokovoy wrote: > On Tue, 25 Nov 2014, Dimitar Georgievski wrote: > >> My case for HTTP load balancing is little different. Ideally I would like >> to use a real load balancer (A10 in this case) for balancing HTTP and >> HTTPS >> services. >> Would that be possible? >> >> Based on the info in this thread, and Apache configuration for IPA >> (ipa.conf) the following steps were performed >> - Added host for sso.example.com >> - Added service for HTTP/sso.example.com >> - added new entry for HTTP/sso.example.com to /etc/httpd/conf/ipa.keytab. >> This keytab is listed in the conf.d/ipa.conf under the Location '/ipa' >> groups of directives. >> ipa-getkeytab -s `hostname` -p HTTP/sso.example.com -k >> /etc/httpd/conf/ipa.keytab >> >> - modifed the conf.d/ipa-rewrite.conf and ipa-pki-proxy.conf to redirect >> requests to sso.example.com >> >> The login page loads but unfortunately authentication is failing with HTTP >> 401 (unauthorized) response from the server. I wonder what I am doing >> wrong. >> > Can you show your /var/log/krb5kdc.log, lines concerning > HTTP/sso.example.com principal at the time you are trying to access IPA > UI. > > FreeIPA limits service principals' ability to impersonate user > principals (or any other principals). FreeIPA UI runs as HTTP/ principal > and is given permission to impersonate user principal when talking to > ldap/ service. This setup is explicit and requires additional > configuration for those Kerberos principals which ask for additional > access. > > For more detailed description read my article at > http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy- > with-FreeIPA/index.html > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariajose1982 at gmail.com Thu Nov 27 12:27:35 2014 From: mariajose1982 at gmail.com (=?UTF-8?Q?Maria_Jose_Ya=C3=B1ez_Dacosta?=) Date: Thu, 27 Nov 2014 10:27:35 -0200 Subject: [Freeipa-users] Freeipa-users Digest, Vol 76, Issue 111 In-Reply-To: References: Message-ID: Hi everyone, I found the following error: "authentication failed (no account associated with Kerberos principal usuipa at FI.EXAMPLE.COM)". I suspect that is missing in FreeIPA give to this user permissions to access by kerberos. what do you think about it ?. I'm newbie in these matters, so I appreciate any help or comments :) Oh!, This is the full error message: ------------------------------------------ LOG --------------------------------------- 2014-11-27 09:35:50,067 WARN [ImapServer-2] [ip=192.168.99.100;] account - authentication failed (no account associated with Kerberos principal usuipa at FI.EXAMPLE.COM) 2014-11-27 09:35:50,068 WARN [ImapServer-2] [ip=192.168.99.100;] imap - SaslServer.evaluateResponse() failed javax.security.sasl.SaslException: Problem with callback handler [Caused by javax.security.sasl.SaslException: usuipa at FI.EXAMPLE.COM is not authorized to connect as usuipa] at com.sun.security.sasl.gsskerb.GssKrb5Server.doHandshake2(GssKrb5Server.java:309) at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:149) at com.zimbra.cs.security.sasl.GssAuthenticator.handle(GssAuthenticator.java:182) at com.zimbra.cs.imap.ImapHandler.continueAuthentication(ImapHandler.java:269) at com.zimbra.cs.imap.ImapHandler.continueAuthentication(ImapHandler.java:260) at com.zimbra.cs.imap.NioImapHandler.processRequest(NioImapHandler.java:121) at com.zimbra.cs.imap.NioImapHandler.messageReceived(NioImapHandler.java:61) at com.zimbra.cs.server.NioHandlerDispatcher.messageReceived(NioHandlerDispatcher.java:88) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at com.zimbra.cs.server.NioLoggingFilter.messageReceived(NioLoggingFilter.java:60) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:780) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:772) at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:714) at java.lang.Thread.run(Thread.java:744) Caused by: javax.security.sasl.SaslException: usuipa at FI.EXAMPLE.COM is not authorized to connect as usuipa at com.sun.security.sasl.gsskerb.GssKrb5Server.doHandshake2(GssKrb5Server.java:301) ... 21 more --------------------------------------- END LOG --------------------------------------- 2014-11-25 16:02 GMT-02:00 Maria Jose Ya?ez Dacosta : > Sorry for delay in answering, I've been testing a few things before going > back to ask. > > Thanks for the advice, I'll be careful with security :). > > I also tried as is explained in the url you shared with me and as you > suspected that isn't the problem either. > > I installed Wireshark, packet capture shows me these errors: > > error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) > e-text: PREAUTH_FAILED > > Where the origin of these packages is the FreeIPA server and the > destination is the Zimbra server. > > I think this may be causing problems. > > I'm ashamed to say this, but haven't known as I have to do to debug Imap > process on the server using KRB5_TRACE. > > Thanks so much for all your help and if you have more suggestions, it > would be appreciated. > > Have a good day. > > > > > 2014-11-25 15:00 GMT-02:00 : > > Send Freeipa-users mailing list submissions to >> freeipa-users at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/freeipa-users >> or, via email, send a message with subject or body 'help' to >> freeipa-users-request at redhat.com >> >> You can reach the person managing the list at >> freeipa-users-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freeipa-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Is it possible to set up SUDO with redudancy? >> (Lukas Slebodnik) >> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 Nov 2014 09:02:59 +0100 >> From: Lukas Slebodnik >> To: William Muriithi >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with >> redudancy? >> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> >> Content-Type: text/plain; charset=utf-8 >> >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < >> william.muriithi at gmail.com> wrote: >> >> > Evening, >> > >> > After looking at almost all the SUDO documentation I could find, it >> looks >> > one has to hardcode FreeIPA hostname on sssd.conf file. Below is what >> red >> > hat advice to add in sssd config file. >> > >> > services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] >> > sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com >> > ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com >> > ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ >> > tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM >> > krb5_server = grobi.idm.coe.muc.redhat.com >> > >> > The implications of adding above is that SUDO would break if the >> > hardcoded ipa is not available even if there is another replica >> somewhere >> > in the network. Is that correct assumption? >> > >> > Is there a better way of doing it that I have missed? >> > >> >> Which version of sssd do you have? >> sssd >= 1.10 has native ipa suod providers and you don't need to use >> "sudo_provider = ldap". >> >> LS >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 25 Nov 2014 10:11:42 +0100 >> From: Petr Spacek >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. >> Message-ID: <547447CE.8090400 at redhat.com> >> Content-Type: text/plain; charset=windows-1252 >> >> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: >> > Thank you for your prompt reply :). >> > >> > I still don't discover what caused the problem, but now I could get more >> > information about the problem. >> > >> > I run the command that you commented me, I did as follows: >> > >> > - kinit usuipa >> > - kvno imap/zimbrafreeipa.example.com at FI.example.com >> > >> > (I said in my previous mail fi.example.com but should have said >> > zimbrafreeipa.example.com. >> > Forgiveness!!). >> > >> > Then run klist and got this: >> > >> > 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ >> FI.EXAMPLE.COM at FI.EXAMPLE.COM >> > 11/24/14 14:05:52 11/25/14 14:04:50 imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >> > >> > Then run >> > KRB5_TRACE=/dev/stdout kvno imap/ >> zimbrafreeipa.example.com at FI.EXAMPLE.COM >> > and got this: >> > --------------------------------------- OUTPUT >> > --------------------------------------------------------------- >> > [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> >> imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >> FILE:/tmp/krb5cc_0 >> > [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >> with >> > result: 0/Conseguido >> > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 >> > --------------------------------------- END OF OUTPUT >> > --------------------------------------------------- >> > >> > When I rum >> > KRB5_TRACE=/dev/stdout thunderbird >> > this show: >> > >> > --------------------------------------- OUTPUT >> > --------------------------------------------------------------- >> > Gtk-Message: Failed to load module "canberra-gtk-module": >> > libcanberra-gtk-module.so: no se puede abrir el fichero del objeto >> > compartido: No existe el fichero o el directorio >> > [20906] 1416845377.323420: ccselect module realm chose cache >> > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >> > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >> > [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> >> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >> > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >> found >> > [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> >> > imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >> > FILE:/tmp/krb5cc_0 >> > [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >> with >> > result: 0/Conseguido >> > [20906] 1416845377.325617: Creating authenticator for >> usuipa at FI.EXAMPLE.COM >> > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, >> > subkey aes256-cts/3BB4, session key aes256-cts/A007 >> > [20906] 1416845377.353847: ccselect module realm chose cache >> > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >> > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >> > [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> >> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >> > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >> found >> > [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey >> > (null), seqnum 1067232298 >> > [20906] 1416845396.10173: ccselect module realm chose cache >> > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >> > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >> > [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> >> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >> > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >> found >> > [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> >> imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >> FILE:/tmp/krb5cc_0 >> > [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >> > zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >> with >> > result: 0/Conseguido >> > [20906] 1416845396.10469: Creating authenticator for >> usuipa at FI.EXAMPLE.COM >> > -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, >> > subkey aes256-cts/5F4D, session key aes256-cts/A007 >> > [20906] 1416845396.35033: ccselect module realm chose cache >> > FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >> server >> > principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >> > [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> >> > krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >> > FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >> found >> > [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey >> > (null), seqnum 911725412 >> > >> > --------------------------------------- END OF OUTPUT >> > --------------------------------------------------- >> >> This seems okay, Thunderbird got necessary ticket so the problem could be >> on >> server side. (Just to be 100% sure: Did you configure >> network.negotiate-auth >> option in Thunderbird according to >> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) >> >> > About permissions on keytab file, I have as following: >> > >> > ls -l /opt/zimbra/conf/krb5.keytab >> > -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab >> > >> > Selinux (/etc/selinux/config) >> > SELINUX=disabled >> > >> > What do you think about this?, >> >> That it is completely insecure :-) Seriously, keytab contains symmetric >> cryptographic keys so it should be protected as much as feasible. >> >> It is fine for testing purposes (assuming that you do not forget to secure >> file permissions and generate new keytab before moving it to production). >> >> As a next step please raise debug levels on the server and possibly use >> KRB5_TRACE=/dev/stdout trick for IMAP server process. >> >> -- >> Petr^2 Spacek >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> End of Freeipa-users Digest, Vol 76, Issue 111 >> ********************************************** >> > > > > -- > Maria Jos? > -- Maria Jos? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Nov 27 13:43:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Nov 2014 14:43:48 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 76, Issue 111 In-Reply-To: References: Message-ID: <54772A94.2090908@redhat.com> On 27.11.2014 13:27, Maria Jose Ya?ez Dacosta wrote: > Hi everyone, > > > I found the following error: "authentication failed (no account associated > with Kerberos principal usuipa at FI.EXAMPLE.COM)". > > I suspect that is missing in FreeIPA give to this user permissions to > access by kerberos. > > what do you think about it ?. > > I'm newbie in these matters, so I appreciate any help or comments :) > > Oh!, This is the full error message: > > ------------------------------------------ LOG > --------------------------------------- > 2014-11-27 09:35:50,067 WARN [ImapServer-2] [ip=192.168.99.100;] account - > authentication failed (no account associated with Kerberos principal > usuipa at FI.EXAMPLE.COM) > 2014-11-27 09:35:50,068 WARN [ImapServer-2] [ip=192.168.99.100;] imap - > SaslServer.evaluateResponse() failed > javax.security.sasl.SaslException: Problem with callback handler [Caused by > javax.security.sasl.SaslException: usuipa at FI.EXAMPLE.COM is not authorized > to connect as usuipa] > at > com.sun.security.sasl.gsskerb.GssKrb5Server.doHandshake2(GssKrb5Server.java:309) > at > com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:149) > at > com.zimbra.cs.security.sasl.GssAuthenticator.handle(GssAuthenticator.java:182) > at > com.zimbra.cs.imap.ImapHandler.continueAuthentication(ImapHandler.java:269) > at > com.zimbra.cs.imap.ImapHandler.continueAuthentication(ImapHandler.java:260) > at > com.zimbra.cs.imap.NioImapHandler.processRequest(NioImapHandler.java:121) > at > com.zimbra.cs.imap.NioImapHandler.messageReceived(NioImapHandler.java:61) > at > com.zimbra.cs.server.NioHandlerDispatcher.messageReceived(NioHandlerDispatcher.java:88) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) > at > com.zimbra.cs.server.NioLoggingFilter.messageReceived(NioLoggingFilter.java:60) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) > at > org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75) > at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:780) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:772) > at > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:714) > at java.lang.Thread.run(Thread.java:744) > Caused by: javax.security.sasl.SaslException: usuipa at FI.EXAMPLE.COM is not > authorized to connect as usuipa Judging from this message, I guess that Zimbra is not configured properly to use LDAP as source of user information. I.e. Kerberos successfully authenticated the user "usuipa at FI.EXAMPLE.COM" but the mapping to an IMAP user is missing. Did you configure Zimbra to use LDAP? You can get some inspiration from http://www.freeipa.org/page/Zimbra_Collaboration_Server_7.2_Authentication_and_GAL_lookups_against_FreeIPA but please note that this how-to is about LDAP authentication, not about Kerberos authentication. Petr^2 Spacek > at > com.sun.security.sasl.gsskerb.GssKrb5Server.doHandshake2(GssKrb5Server.java:301) > ... 21 more > > --------------------------------------- END LOG > --------------------------------------- > > > > > 2014-11-25 16:02 GMT-02:00 Maria Jose Ya?ez Dacosta > : > >> Sorry for delay in answering, I've been testing a few things before going >> back to ask. >> >> Thanks for the advice, I'll be careful with security :). >> >> I also tried as is explained in the url you shared with me and as you >> suspected that isn't the problem either. >> >> I installed Wireshark, packet capture shows me these errors: >> >> error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) >> e-text: PREAUTH_FAILED >> >> Where the origin of these packages is the FreeIPA server and the >> destination is the Zimbra server. >> >> I think this may be causing problems. >> >> I'm ashamed to say this, but haven't known as I have to do to debug Imap >> process on the server using KRB5_TRACE. >> >> Thanks so much for all your help and if you have more suggestions, it >> would be appreciated. >> >> Have a good day. >> >> >> >> >> 2014-11-25 15:00 GMT-02:00 : >> >> Send Freeipa-users mailing list submissions to >>> freeipa-users at redhat.com >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> or, via email, send a message with subject or body 'help' to >>> freeipa-users-request at redhat.com >>> >>> You can reach the person managing the list at >>> freeipa-users-owner at redhat.com >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Freeipa-users digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Is it possible to set up SUDO with redudancy? >>> (Lukas Slebodnik) >>> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 25 Nov 2014 09:02:59 +0100 >>> From: Lukas Slebodnik >>> To: William Muriithi >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with >>> redudancy? >>> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com> >>> Content-Type: text/plain; charset=utf-8 >>> >>> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < >>> william.muriithi at gmail.com> wrote: >>> >>>> Evening, >>>> >>>> After looking at almost all the SUDO documentation I could find, it >>> looks >>>> one has to hardcode FreeIPA hostname on sssd.conf file. Below is what >>> red >>>> hat advice to add in sssd config file. >>>> >>>> services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] >>>> sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com >>>> ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com >>>> ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ >>>> tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM >>>> krb5_server = grobi.idm.coe.muc.redhat.com >>>> >>>> The implications of adding above is that SUDO would break if the >>>> hardcoded ipa is not available even if there is another replica >>> somewhere >>>> in the network. Is that correct assumption? >>>> >>>> Is there a better way of doing it that I have missed? >>>> >>> >>> Which version of sssd do you have? >>> sssd >= 1.10 has native ipa suod providers and you don't need to use >>> "sudo_provider = ldap". >>> >>> LS >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Tue, 25 Nov 2014 10:11:42 +0100 >>> From: Petr Spacek >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. >>> Message-ID: <547447CE.8090400 at redhat.com> >>> Content-Type: text/plain; charset=windows-1252 >>> >>> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: >>>> Thank you for your prompt reply :). >>>> >>>> I still don't discover what caused the problem, but now I could get more >>>> information about the problem. >>>> >>>> I run the command that you commented me, I did as follows: >>>> >>>> - kinit usuipa >>>> - kvno imap/zimbrafreeipa.example.com at FI.example.com >>>> >>>> (I said in my previous mail fi.example.com but should have said >>>> zimbrafreeipa.example.com. >>>> Forgiveness!!). >>>> >>>> Then run klist and got this: >>>> >>>> 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ >>> FI.EXAMPLE.COM at FI.EXAMPLE.COM >>>> 11/24/14 14:05:52 11/25/14 14:04:50 imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>>> >>>> Then run >>>> KRB5_TRACE=/dev/stdout kvno imap/ >>> zimbrafreeipa.example.com at FI.EXAMPLE.COM >>>> and got this: >>>> --------------------------------------- OUTPUT >>>> --------------------------------------------------------------- >>>> [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM -> >>> imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >>> FILE:/tmp/krb5cc_0 >>>> [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >>> with >>>> result: 0/Conseguido >>>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM: kvno = 2 >>>> --------------------------------------- END OF OUTPUT >>>> --------------------------------------------------- >>>> >>>> When I rum >>>> KRB5_TRACE=/dev/stdout thunderbird >>>> this show: >>>> >>>> --------------------------------------- OUTPUT >>>> --------------------------------------------------------------- >>>> Gtk-Message: Failed to load module "canberra-gtk-module": >>>> libcanberra-gtk-module.so: no se puede abrir el fichero del objeto >>>> compartido: No existe el fichero o el directorio >>>> [20906] 1416845377.323420: ccselect module realm chose cache >>>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >>> server >>>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>>> [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM -> >>>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >>> found >>>> [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM -> >>>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >>>> FILE:/tmp/krb5cc_0 >>>> [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >>> with >>>> result: 0/Conseguido >>>> [20906] 1416845377.325617: Creating authenticator for >>> usuipa at FI.EXAMPLE.COM >>>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 138355536, >>>> subkey aes256-cts/3BB4, session key aes256-cts/A007 >>>> [20906] 1416845377.353847: ccselect module realm chose cache >>>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >>> server >>>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>>> [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM -> >>>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >>> found >>>> [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey >>>> (null), seqnum 1067232298 >>>> [20906] 1416845396.10173: ccselect module realm chose cache >>>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >>> server >>>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>>> [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM -> >>>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >>> found >>>> [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM -> >>> imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache >>> FILE:/tmp/krb5cc_0 >>>> [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/ >>>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 >>> with >>>> result: 0/Conseguido >>>> [20906] 1416845396.10469: Creating authenticator for >>> usuipa at FI.EXAMPLE.COM >>>> -> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM, seqnum 592157704, >>>> subkey aes256-cts/5F4D, session key aes256-cts/A007 >>>> [20906] 1416845396.35033: ccselect module realm chose cache >>>> FILE:/tmp/krb5cc_0 with client principal usuipa at FI.EXAMPLE.COM for >>> server >>>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM >>>> [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM -> >>>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from >>>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not >>> found >>>> [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey >>>> (null), seqnum 911725412 >>>> >>>> --------------------------------------- END OF OUTPUT >>>> --------------------------------------------------- >>> >>> This seems okay, Thunderbird got necessary ticket so the problem could be >>> on >>> server side. (Just to be 100% sure: Did you configure >>> network.negotiate-auth >>> option in Thunderbird according to >>> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) >>> >>>> About permissions on keytab file, I have as following: >>>> >>>> ls -l /opt/zimbra/conf/krb5.keytab >>>> -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab >>>> >>>> Selinux (/etc/selinux/config) >>>> SELINUX=disabled >>>> >>>> What do you think about this?, >>> >>> That it is completely insecure :-) Seriously, keytab contains symmetric >>> cryptographic keys so it should be protected as much as feasible. >>> >>> It is fine for testing purposes (assuming that you do not forget to secure >>> file permissions and generate new keytab before moving it to production). >>> >>> As a next step please raise debug levels on the server and possibly use >>> KRB5_TRACE=/dev/stdout trick for IMAP server process. >>> >>> -- >>> Petr^2 Spacek From pvoborni at redhat.com Thu Nov 27 16:59:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Nov 2014 17:59:35 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.1.2 Message-ID: <54775877.6060102@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.2 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.2 == === Bug fixes === * CVE-2014-7850: ensure that user input is properly escaped to prevent XSS attacks [https://fedorahosted.org/freeipa/ticket/4742] [http://www.freeipa.org/page/CVE-2014-7850] * harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2 * fixed getkeytab operation [https://fedorahosted.org/freeipa/ticket/4718] [https://fedorahosted.org/freeipa/ticket/4728] * backup and restore fixes related to certificates restore and SELinux context * static code analysis fixes * various small fixes == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.1.1 == === Alexander Bokovoy (2) === * Update slapi-nis dependency to pull 0.54.1 * AD trust: improve trust validation === David Kupka (6) === * Remove unneeded internal methods. Move code to public methods. * Remove service file even if it isn't link. * Produce better error in group-add command. * Fix --{user,group}-ignore-attribute in migration plugin. * ipa-restore: Check if directory is provided + better errors. * Fix error message for nonexistent members and add tests. === Gabe Alford (1) === * ipa-server-install Directory Manager help incorrect === Jan Cholasta (15) === * Fix CA certificate backup and restore * Update Requires on pki-ca to 10.2.1-0.1 * Fix wrong expiration date on renewed IPA CA certificates * Restore file extended attributes and SELinux context in ipa-restore * Use correct service name in cainstance.backup_config * Stop tracking certificates before restoring them in ipa-restore * Remove redefinition of LOG from ipa-otp-lasttoken * Unload P11_Helper object's library when it is finalized in ipap11helper * Fix Kerberos error handling in ipa-sam * Fix unchecked return value in ipa-kdb * Fix unchecked return values in ipa-winsync * Fix unchecked return value in ipa-join * Fix unchecked return value in krb5 common utils * Fix memory leak in GetKeytabControl asn1 code * Add TLS 1.2 to the protocol list in mod_nss config === Martin Ba?ti (12) === * Fix: DNS installer adds invalid zonemgr email * Fix: DNS policy upgrade raises asertion error * Fix upgrade referint plugin * Upgrade: fix trusts objectclass violationi * Fix named working directory permissions * Fix: zonemgr must be unicode value * Fix warning message should not contain CLI commands * Show warning instead of error if CA did not start * Raise right exception if domain name is not valid * Fix pk11helper module compiler warnings * Fix: read_ip_addresses should return ipaddr object * Fix detection of encoding in zonemgr option === Martin Ko?ek (1) === * Lower pki-ca requires to 10.1.2 === Nathaniel McCallum (3) === * Improve otptoken help messages * Ensure users exist when assigning tokens to them * Enable QR code display by default in otptoken-add === Petr Viktorin (5) === * ipa-restore: Don't crash if AD trust is not installed * ipaplatform: Use the dirsrv service, not target * Do not restore SELinux settings that were not backed up * Add additional backup & restore checks * copy_schema_to_ca: Fallback to old import location for ipaplatform.services === Petr Voborn?k (9) === * ranges: prohibit setting --rid-base with ipa-trust-ad-posix type * unittests: baserid for ipa-ad-trust-posix idranges * ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges * idrange: include raw range type in output * webui: prohibit setting rid base with ipa-trust-ad-posix type * webui: fix potential XSS vulnerabilities * restore: clear httpd ccache after restore * webui: use domain name instead of domain SID in idrange adder dialog * webui: normalize idview tab labels === Petr ?pa?ek (1) === * Fix minimal version of BIND for Fedora 20 and 21 === Rob Crittenden (2) === * Search using proper scope when connecting CA instances * Use NSS protocol range API to set available TLS protocols === Simo Sorce (4) === * Add UTC date to GIT snapshot version generation * Fix filtering of enctypes in server code. * Add asn1c generated code for keytab controls * Use asn1c helpers to encode/decode the getkeytab control === Thorsten Scherf (1) === * Add help string on how to configure multiple DNS forwards for various cli tools -- Petr Vobornik From jeldo26 at live.com Fri Nov 28 09:39:59 2014 From: jeldo26 at live.com (Eldo Joseph) Date: Fri, 28 Nov 2014 09:39:59 +0000 Subject: [Freeipa-users] IPA V3 Backup and recovery Message-ID: Hi All, Can some one help me, with the best practices which can be used for IPAV3 backup and recovery, currently it is been a kind of single point of failure. Current infrastructure: One Master serverFive clients. I've tried with db2bak and bak2db features, I was able for a successful restore. how ever IPA admintools commands are failing with this error. (info): TGS_REQ (4 etypes {18 17 16 23}) xx.xx.xx.xx : PROCESS_TGS: authtime 0, for , Decrypt integrity check failed Thanks,Eldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Nov 28 09:56:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 28 Nov 2014 10:56:43 +0100 Subject: [Freeipa-users] IPA V3 Backup and recovery In-Reply-To: References: Message-ID: <547846DB.803@redhat.com> On 11/28/2014 10:39 AM, Eldo Joseph wrote: > Hi All, > Can some one help me, with the best practices which can be used for IPAV3 backup and recovery, currently it is been a kind of single point of failure. > Current infrastructure: One Master serverFive clients. > I've tried with db2bak and bak2db features, I was able for a successful restore. how ever IPA admintools commands are failing with this error. > (info): TGS_REQ (4 etypes {18 17 16 23}) xx.xx.xx.xx : PROCESS_TGS: authtime 0, for , Decrypt integrity check failed > Thanks,Eldo. > Hello Eldo, sounds like: https://fedorahosted.org/freeipa/ticket/4726 try to run: sudo -u apache kdestroy after the restore -- Petr Vobornik From rcritten at redhat.com Sat Nov 29 17:24:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 29 Nov 2014 12:24:12 -0500 Subject: [Freeipa-users] IPA V3 Backup and recovery In-Reply-To: <547846DB.803@redhat.com> References: <547846DB.803@redhat.com> Message-ID: <547A013C.10703@redhat.com> Petr Vobornik wrote: > On 11/28/2014 10:39 AM, Eldo Joseph wrote: >> Hi All, >> Can some one help me, with the best practices which can be used for >> IPAV3 backup and recovery, currently it is been a kind of single >> point of failure. >> Current infrastructure: One Master serverFive clients. >> I've tried with db2bak and bak2db features, I was able for a >> successful restore. how ever IPA admintools commands are failing with >> this error. >> (info): TGS_REQ (4 etypes {18 17 16 23}) xx.xx.xx.xx : PROCESS_TGS: >> authtime 0, for , Decrypt integrity >> check failed >> Thanks,Eldo. >> > Hello Eldo, > > sounds like: https://fedorahosted.org/freeipa/ticket/4726 > > try to run: > sudo -u apache kdestroy > after the restore You may also want to look at the design for backup and restore, http://www.freeipa.org/page/V3/Backup_and_Restore . Quite a lot needs to happen for a proper backup and restore, particularly since you have multiple masters. rob