From tmaugh at boingo.com Sat Feb 1 00:00:30 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Sat, 1 Feb 2014 00:00:30 +0000 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <52EC3898.8020503@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local>, <52EC15D3.6060705@redhat.com> <6FB698E172A95F49BE009B36D56F53E226AACD@EXCHMB1-ELS.BWINC.local>, <52EC3898.8020503@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226ACB6@EXCHMB1-ELS.BWINC.local> got a new CA cert and seem to be in buisness [root at se-idm-01.boingo.com cacerts]$ ipa-replica-manage connect --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, dc=local" --bindpw "g0_b0ing0" --passsync "l0v3ish at rd" --cacert=/etc/openldap/cacerts/skywarp.cer qatestdc2.boingoqa.local -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/skywarp.cer to certificate database for se-idm-01.boingo.com ipa: INFO: AD Suffix is: DC=boingoqa,DC=local The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com 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 Update in progress Update in progress Update in progress Update succeeded Connected 'se-idm-01.boingo.com' to 'qatestdc2.boingoqa.local' then ran your command [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) ldap_create ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.194.55.48:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1b7c160 msgid 1 wait4msg ld 0x1b7c160 msgid 1 (infinite timeout) wait4msg continue ld 0x1b7c160 msgid 1 all 1 ** ld 0x1b7c160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:09 2014 ** ld 0x1b7c160 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1b7c160 request count 1 (abandoned 0) ** ld 0x1b7c160 Response Queue: Empty ld 0x1b7c160 response count 0 ldap_chkResponseList ld 0x1b7c160 msgid 1 all 1 ldap_chkResponseList returns ld 0x1b7c160 NULL ldap_int_select read1msg: ld 0x1b7c160 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x1b7c160 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1b7c160 0 new referrals read1msg: mark request completed, ld 0x1b7c160 msgid 1 request done: ld 0x1b7c160 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . TLS: loaded CA certificate file /etc/ipa/ca.crt. TLS: certificate [CN=QATESTDC2.boingoqa.local] is valid TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 66 bytes to sd 3 ldap_result ld 0x1b7c160 msgid 2 wait4msg ld 0x1b7c160 msgid 2 (infinite timeout) wait4msg continue ld 0x1b7c160 msgid 2 all 1 ** ld 0x1b7c160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:13 2014 ** ld 0x1b7c160 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x1b7c160 request count 1 (abandoned 0) ** ld 0x1b7c160 Response Queue: Empty ld 0x1b7c160 response count 0 ldap_chkResponseList ld 0x1b7c160 msgid 2 all 1 ldap_chkResponseList returns ld 0x1b7c160 NULL ldap_int_select read1msg: ld 0x1b7c160 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 104 contents: read1msg: ld 0x1b7c160 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x1b7c160 0 new referrals read1msg: mark request completed, ld 0x1b7c160 msgid 2 request done: ld 0x1b7c160 msgid 2 res_errno: 49, res_error: <80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) ldap_create ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.194.55.48:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1fe2160 msgid 1 wait4msg ld 0x1fe2160 msgid 1 (infinite timeout) wait4msg continue ld 0x1fe2160 msgid 1 all 1 ** ld 0x1fe2160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:19 2014 ** ld 0x1fe2160 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1fe2160 request count 1 (abandoned 0) ** ld 0x1fe2160 Response Queue: Empty ld 0x1fe2160 response count 0 ldap_chkResponseList ld 0x1fe2160 msgid 1 all 1 ldap_chkResponseList returns ld 0x1fe2160 NULL ldap_int_select read1msg: ld 0x1fe2160 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x1fe2160 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1fe2160 0 new referrals read1msg: mark request completed, ld 0x1fe2160 msgid 1 request done: ld 0x1fe2160 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . TLS: loaded CA certificate file /etc/ipa/ca.crt. TLS: certificate [CN=QATESTDC2.boingoqa.local] is valid TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 65 bytes to sd 3 ldap_result ld 0x1fe2160 msgid 2 wait4msg ld 0x1fe2160 msgid 2 (infinite timeout) wait4msg continue ld 0x1fe2160 msgid 2 all 1 ** ld 0x1fe2160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:23 2014 ** ld 0x1fe2160 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x1fe2160 request count 1 (abandoned 0) ** ld 0x1fe2160 Response Queue: Empty ld 0x1fe2160 response count 0 ldap_chkResponseList ld 0x1fe2160 msgid 2 all 1 ldap_chkResponseList returns ld 0x1fe2160 NULL ldap_int_select read1msg: ld 0x1fe2160 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1fe2160 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x1fe2160 0 new referrals read1msg: mark request completed, ld 0x1fe2160 msgid 2 request done: ld 0x1fe2160 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "objectclass=*" put_filter: default put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 85 bytes to sd 3 ldap_result ld 0x1fe2160 msgid -1 wait4msg ld 0x1fe2160 msgid -1 (infinite timeout) wait4msg continue ld 0x1fe2160 msgid -1 all 0 ** ld 0x1fe2160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:23 2014 ** ld 0x1fe2160 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1fe2160 request count 1 (abandoned 0) ** ld 0x1fe2160 Response Queue: Empty ld 0x1fe2160 response count 0 ldap_chkResponseList ld 0x1fe2160 msgid -1 all 0 ldap_chkResponseList returns ld 0x1fe2160 NULL ldap_int_select read1msg: ld 0x1fe2160 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 59 contents: read1msg: ld 0x1fe2160 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x1fe2160 msgid -1 wait4msg ld 0x1fe2160 msgid -1 (infinite timeout) wait4msg continue ld 0x1fe2160 msgid -1 all 0 ** ld 0x1fe2160 Connections: * host: qatestdc2.boingoqa.local port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 31 23:59:23 2014 ** ld 0x1fe2160 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x1fe2160 request count 1 (abandoned 0) ** ld 0x1fe2160 Response Queue: Empty ld 0x1fe2160 response count 0 ldap_chkResponseList ld 0x1fe2160 msgid -1 all 0 ldap_chkResponseList returns ld 0x1fe2160 NULL read1msg: ld 0x1fe2160 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x1fe2160 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1fe2160 0 new referrals read1msg: mark request completed, ld 0x1fe2160 msgid 3 request done: ld 0x1fe2160 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, January 31, 2014 3:58 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] cant create winsync reolication On 01/31/2014 04:13 PM, Todd Maugh wrote: asked: Can you provide your /etc/openldap/ldap.conf? answer: /etc/openldap/ldap.con #File modified by ipa-client-install URI ldaps://se-idm-01.boingo.com BASE dc=boingo,dc=com TLS_CACERT /etc/ipa/ca.crt TLS_CACERTDIR /etc/openldap/cacerts/ TLS_REQCERT allow This will allow errors where the hostname in the cert subject DN does not match the IP address or vice versa. What happens if you set it to TLS_REQCERT demand? Or, if you don't want to touch this file (because it will probably break other things), try this: LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn If that works, then please provide the output of rpm -q 389-ds-base openldap nss ping TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error -8179:Peer's Certificate issuer is not recognized.. This is saying QATESTDC2.boingoqa.local cannot be resolved - or the IP address does not match. This is usually a problem, but perhaps you have set your ldap.conf to continue despite this problem? PING qatestdc2.boingoqa.local (10.194.55.48) 56(84) bytes of data. 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=1 ttl=124 time=0.559 ms 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=2 ttl=124 time=0.660 ms ^C --- qatestdc2.boingoqa.local ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1070ms rtt min/avg/max/mdev = 0.559/0.609/0.660/0.056 ms Ok. Does 10.194.55.48 resolve to qatestdc2.boingoqa.local? TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Sat Feb 1 00:08:03 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 31 Jan 2014 17:08:03 -0700 Subject: [Freeipa-users] cant create winsync reolication In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226ACB6@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2268FE3@EXCHMB1-ELS.BWINC.local>, <52EBE850.9070108@redhat.com> <2AAD1D7C-EDB5-43C1-A51F-F41802EBBD88@boingo.com>, <52EBEB74.5000100@redhat.com> <6FB698E172A95F49BE009B36D56F53E226A3C6@EXCHMB1-ELS.BWINC.local>, <52EC09E5.1030604@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226A668@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226A6D1@EXCHMB1-ELS.BWINC.local>, <52EC15D3.6060705@redhat.com> <6FB698E172A95F49BE009B36D56F53E226AACD@EXCHMB1-ELS.BWINC.local>, <52EC3898.8020503@redhat.com> <6FB698E172A95F49BE009B36D56F53E226ACB6@EXCHMB1-ELS.BWINC.local> Message-ID: <52EC3AE3.4000303@redhat.com> On 01/31/2014 05:00 PM, Todd Maugh wrote: > got a new CA cert and seem to be in buisness > > [root at se-idm-01.boingo.com cacerts]$ ipa-replica-manage connect > --winsync --binddn "cn=idm admin, cn=Users, dc=boingoqa, dc=local" > --bindpw "g0_b0ing0" --passsync "l0v3ish at rd" > --cacert=/etc/openldap/cacerts/skywarp.cer qatestdc2.boingoqa.local -v > Directory Manager password: > > Added CA certificate /etc/openldap/cacerts/skywarp.cer to certificate > database for se-idm-01.boingo.com > ipa: INFO: AD Suffix is: DC=boingoqa,DC=local > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=boingo,dc=com > 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 > Update in progress > Update in progress > Update in progress > Update succeeded > Connected 'se-idm-01.boingo.com' to 'qatestdc2.boingoqa.local' Great! > > > then ran your command > > > [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_REQCERT=demand > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx > -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) > ldap_create > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying 10.194.55.48:389 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > ldap_open_defconn: successful > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 31 bytes to sd 3 > ldap_result ld 0x1b7c160 msgid 1 > wait4msg ld 0x1b7c160 msgid 1 (infinite timeout) > wait4msg continue ld 0x1b7c160 msgid 1 all 1 > ** ld 0x1b7c160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:09 2014 > > > ** ld 0x1b7c160 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1b7c160 request count 1 (abandoned 0) > ** ld 0x1b7c160 Response Queue: > Empty > ld 0x1b7c160 response count 0 > ldap_chkResponseList ld 0x1b7c160 msgid 1 all 1 > ldap_chkResponseList returns ld 0x1b7c160 NULL > ldap_int_select > read1msg: ld 0x1b7c160 msgid 1 all 1 > ber_get_next > ber_get_next: tag 0x30 len 40 contents: > read1msg: ld 0x1b7c160 msgid 1 message type extended-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1b7c160 0 new referrals > read1msg: mark request completed, ld 0x1b7c160 msgid 1 > request done: ld 0x1b7c160 msgid 1 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 1, msgid 1) > ldap_parse_extended_result > ber_scanf fmt ({eAA) ber: > ber_scanf fmt (a) ber: > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (x) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' > tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly > TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . > TLS: loaded CA certificate file /etc/ipa/ca.crt. > TLS: certificate [CN=QATESTDC2.boingoqa.local] is valid > TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, > issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security > level: high, secret key bits: 128, total key bits: 128, cache hits: 0, > cache misses: 0, cache not reusable: 0 > Enter LDAP Password: > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({i) ber: > ber_flush2: 66 bytes to sd 3 > ldap_result ld 0x1b7c160 msgid 2 > wait4msg ld 0x1b7c160 msgid 2 (infinite timeout) > wait4msg continue ld 0x1b7c160 msgid 2 all 1 > ** ld 0x1b7c160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:13 2014 > > > ** ld 0x1b7c160 Outstanding Requests: > * msgid 2, origid 2, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1b7c160 request count 1 (abandoned 0) > ** ld 0x1b7c160 Response Queue: > Empty > ld 0x1b7c160 response count 0 > ldap_chkResponseList ld 0x1b7c160 msgid 2 all 1 > ldap_chkResponseList returns ld 0x1b7c160 NULL > ldap_int_select > read1msg: ld 0x1b7c160 msgid 2 all 1 > ber_get_next > ber_get_next: tag 0x30 len 104 contents: > read1msg: ld 0x1b7c160 msgid 2 message type bind > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1b7c160 0 new referrals > read1msg: mark request completed, ld 0x1b7c160 msgid 2 > request done: ld 0x1b7c160 msgid 2 > res_errno: 49, res_error: <80090308: LdapErr: DSID-0C0903A9, comment: > AcceptSecurityContext error, data 52e, v1db1>, res_matched: <> > ldap_free_request (origid 2, msgid 2) > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_err2string > ldap_bind: Invalid credentials (49) > additional info: 80090308: LdapErr: DSID-0C0903A9, comment: > AcceptSecurityContext error, data 52e, v1db1 > [root at se-idm-01.boingo.com cacerts]$ LDAPTLS_REQCERT=demand > LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ ldapsearch -d 1 -LLLx > -ZZ -H ldap://qatestdc2.boingoqa.local -b "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local) > ldap_create > ldap_url_parse_ext(ldap://qatestdc2.boingoqa.local:389/??base) > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP qatestdc2.boingoqa.local:389 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying 10.194.55.48:389 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > ldap_open_defconn: successful > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 31 bytes to sd 3 > ldap_result ld 0x1fe2160 msgid 1 > wait4msg ld 0x1fe2160 msgid 1 (infinite timeout) > wait4msg continue ld 0x1fe2160 msgid 1 all 1 > ** ld 0x1fe2160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:19 2014 > > > ** ld 0x1fe2160 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1fe2160 request count 1 (abandoned 0) > ** ld 0x1fe2160 Response Queue: > Empty > ld 0x1fe2160 response count 0 > ldap_chkResponseList ld 0x1fe2160 msgid 1 all 1 > ldap_chkResponseList returns ld 0x1fe2160 NULL > ldap_int_select > read1msg: ld 0x1fe2160 msgid 1 all 1 > ber_get_next > ber_get_next: tag 0x30 len 40 contents: > read1msg: ld 0x1fe2160 msgid 1 message type extended-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1fe2160 0 new referrals > read1msg: mark request completed, ld 0x1fe2160 msgid 1 > request done: ld 0x1fe2160 msgid 1 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 1, msgid 1) > ldap_parse_extended_result > ber_scanf fmt ({eAA) ber: > ber_scanf fmt (a) ber: > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (x) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > TLS: certdb config: configDir='/etc/dirsrv/slapd-BOINGO-COM/' > tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly > TLS: using moznss security dir /etc/dirsrv/slapd-BOINGO-COM/ prefix . > TLS: loaded CA certificate file /etc/ipa/ca.crt. > TLS: certificate [CN=QATESTDC2.boingoqa.local] is valid > TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, > issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security > level: high, secret key bits: 128, total key bits: 128, cache hits: 0, > cache misses: 0, cache not reusable: 0 > Enter LDAP Password: > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({i) ber: > ber_flush2: 65 bytes to sd 3 > ldap_result ld 0x1fe2160 msgid 2 > wait4msg ld 0x1fe2160 msgid 2 (infinite timeout) > wait4msg continue ld 0x1fe2160 msgid 2 all 1 > ** ld 0x1fe2160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:23 2014 > > > ** ld 0x1fe2160 Outstanding Requests: > * msgid 2, origid 2, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1fe2160 request count 1 (abandoned 0) > ** ld 0x1fe2160 Response Queue: > Empty > ld 0x1fe2160 response count 0 > ldap_chkResponseList ld 0x1fe2160 msgid 2 all 1 > ldap_chkResponseList returns ld 0x1fe2160 NULL > ldap_int_select > read1msg: ld 0x1fe2160 msgid 2 all 1 > ber_get_next > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x1fe2160 msgid 2 message type bind > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1fe2160 0 new referrals > read1msg: mark request completed, ld 0x1fe2160 msgid 2 > request done: ld 0x1fe2160 msgid 2 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 2, msgid 2) > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_search_ext > put_filter: "objectclass=*" > put_filter: default > put_simple_filter: "objectclass=*" > ldap_send_initial_request > ldap_send_server_request > ber_scanf fmt ({it) ber: > ber_scanf fmt ({) ber: > ber_flush2: 85 bytes to sd 3 > ldap_result ld 0x1fe2160 msgid -1 > wait4msg ld 0x1fe2160 msgid -1 (infinite timeout) > wait4msg continue ld 0x1fe2160 msgid -1 all 0 > ** ld 0x1fe2160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:23 2014 > > > ** ld 0x1fe2160 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1fe2160 request count 1 (abandoned 0) > ** ld 0x1fe2160 Response Queue: > Empty > ld 0x1fe2160 response count 0 > ldap_chkResponseList ld 0x1fe2160 msgid -1 all 0 > ldap_chkResponseList returns ld 0x1fe2160 NULL > ldap_int_select > read1msg: ld 0x1fe2160 msgid -1 all 0 > ber_get_next > ber_get_next: tag 0x30 len 59 contents: > read1msg: ld 0x1fe2160 msgid 3 message type search-entry > ldap_get_dn_ber > ber_scanf fmt ({ml{) ber: > dn: CN=IDM ADMIN,CN=Users,DC=boingoqa,DC=local > ber_scanf fmt ({xx) ber: > ldap_get_attribute_ber > ldap_msgfree > ldap_result ld 0x1fe2160 msgid -1 > wait4msg ld 0x1fe2160 msgid -1 (infinite timeout) > wait4msg continue ld 0x1fe2160 msgid -1 all 0 > ** ld 0x1fe2160 Connections: > * host: qatestdc2.boingoqa.local port: 389 (default) > refcnt: 2 status: Connected > last used: Fri Jan 31 23:59:23 2014 > > > ** ld 0x1fe2160 Outstanding Requests: > * msgid 3, origid 3, status InProgress > outstanding referrals 0, parent count 0 > ld 0x1fe2160 request count 1 (abandoned 0) > ** ld 0x1fe2160 Response Queue: > Empty > ld 0x1fe2160 response count 0 > ldap_chkResponseList ld 0x1fe2160 msgid -1 all 0 > ldap_chkResponseList returns ld 0x1fe2160 NULL > read1msg: ld 0x1fe2160 msgid -1 all 0 > ber_get_next > ber_get_next: tag 0x30 len 16 contents: > read1msg: ld 0x1fe2160 msgid 3 message type search-result > ber_scanf fmt ({eAA) ber: > read1msg: ld 0x1fe2160 0 new referrals > read1msg: mark request completed, ld 0x1fe2160 msgid 3 > request done: ld 0x1fe2160 msgid 3 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 3, msgid 3) > > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_scanf fmt (}) ber: > ldap_msgfree > ldap_free_connection 1 1 > ldap_send_unbind > ber_flush2: 7 bytes to sd 3 > ldap_free_connection: actually freed > > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Friday, January 31, 2014 3:58 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] cant create winsync reolication > > On 01/31/2014 04:13 PM, Todd Maugh wrote: >> >> asked: Can you provide your /etc/openldap/ldap.conf? >> >> >> answer: >> >> /etc/openldap/ldap.con >> #File modified by ipa-client-install >> >> URI ldaps://se-idm-01.boingo.com >> BASE dc=boingo,dc=com >> TLS_CACERT /etc/ipa/ca.crt >> TLS_CACERTDIR /etc/openldap/cacerts/ >> TLS_REQCERT allow > > This will allow errors where the hostname in the cert subject DN does > not match the IP address or vice versa. > > What happens if you set it to TLS_REQCERT demand? > > Or, if you don't want to touch this file (because it will probably > break other things), try this: > > LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-BOINGO-COM/ > ldapsearch -d 1 -LLLx -ZZ -H ldap://qatestdc2.boingoqa.local -b > "cn=idm admin,cn=users,dc=boingoqa,dc=local" -D "cn=idm > admin,cn=users,dc=boingoqa,dc=local" -W 'objectclass=*' dn > > If that works, then please provide the output of > > rpm -q 389-ds-base openldap nss > >> ping >> >>> TLS: certificate [CN=QATESTDC2.boingoqa.local] is not valid - error >>> -8179:Peer's Certificate issuer is not recognized.. >> >> This is saying QATESTDC2.boingoqa.local cannot be resolved - or the >> IP address does not match. >> >> This is usually a problem, but perhaps you have set your ldap.conf to >> continue despite this problem? >> PING qatestdc2.boingoqa.local (10.194.55.48) 56(84) bytes of data. >> 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=1 >> ttl=124 time=0.559 ms >> 64 bytes from qatestdc2.boingoqa.local (10.194.55.48): icmp_seq=2 >> ttl=124 time=0.660 ms >> ^C >> --- qatestdc2.boingoqa.local ping statistics --- >> 2 packets transmitted, 2 received, 0% packet loss, time 1070ms >> rtt min/avg/max/mdev = 0.559/0.609/0.660/0.056 ms > > Ok. Does 10.194.55.48 resolve to qatestdc2.boingoqa.local? > >> >> >> >> >>> TLS certificate verification: subject: CN=QATESTDC2.boingoqa.local, >>> issuer: CN=SKYWARPCA,DC=boingoqa,DC=local, cipher: AES-128, security >>> level: high, secret key bits: 128, total key bits: 128, cache hits: >>> 0, cache misses: 0, cache not reusable: 0 >>> Enter LDAP Password: >>> ldap_sasl_bind >>> ldap_send_initial_request >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 3 16:32:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Feb 2014 17:32:53 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52EBFA5C.4070601@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> Message-ID: <52EFC4B5.90807@redhat.com> On 01/31/2014 08:32 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> >> >> >> On Fri, January 17, 2014 16:37, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>> >>>> >>>> This worked better than expected. Thank you! :) >>>> >>>> >>>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays >>>> any certificates out >>>> of date, and all certificates in need of renewal within 28 days has been >>>> renewed. The webui also >>>> started working again and things seem to be back to normal. >>>> >>>> ipa03 however is still having issues. I could not renew any certificates on >>>> this server to begin >>>> with, but I managed to renew the certificates for the directory servers by >>>> changing the xmlrpc >>>> url to another ipa server in /etc/ipa/default.conf and resubmitting these >>>> requests. >>>> >>>> "getcert resubmit -i >>> NEED_GUIDANCE after a short while for the certificates for the PKI service. >>>> >>>> >>>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >>>> Updated certificate for ipaCert not available". >>>> >>>> >>>> There is a lot of information in the /var/log/pki-ca/debug, but nothing >>>> that I can easily distinguish as an error from all the other output. >>>> Anything in particular I >>>> should look for? >>> >>> Ok, so this is a bug in IPA related to python readline. Garbage is >>> getting inserted and causing bad things to happen, >>> https://fedorahosted.org/freeipa/ticket/4064 >>> >>> >>> So the question is, are the certs available or not. >>> >>> >>> A number of the same certificates are shared amongst all the CAs. One >>> does the renewal and stuffs the result into >>> cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs >>> refer to that location for an updated cert and will load them if they are >>> updated. >>> >>> Look to see if the certs are updated there. Given that you have 2 >>> working masters I'm assuming that is the case, so it may just be a matter of >>> fixing the python. >>> >> >> I could not get anywhere even after manually patching the python script as >> mentioned in the ticket >> you provided. >> >> >> I ended up removing and re-adding the replica during a maintenance window. >> For future reference, >> what I did was to remove the replica as per the Identity Management Guide on >> docs.redhat.com. I >> then re-created the replica installation file and installed the replica. >> >> At this point Certmonger managed to retrieve new certificates for the expired >> certificates, but it >> kept segfaulting when it attempted to save the certificate to disk. I >> restarted certmonger a few >> times, but certmonger just ended up segfaulting over and over. I decided to >> block the ipa server >> off the network and change the date back to before the certs expired. After >> the date was changed I >> restarted certmonger. Certmonger managed to save the certs successfully this >> time and a "getcert >> list" now displays only certificates with an expire date of 2015 or 2016 and >> a status of >> MONTORING. >> >> I changed the date back to correct date and time and removed the iptables >> rules. The replica now >> works just fine. >> >> Thank you for your assistance. > > Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1032760 > > rob This one might be related as well: https://bugzilla.redhat.com/show_bug.cgi?id=1040009. Martin From steve at altosresearch.com Mon Feb 3 18:49:48 2014 From: steve at altosresearch.com (Steve Severance) Date: Mon, 3 Feb 2014 10:49:48 -0800 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: <20140203124051.GC16123@localhost.localdomain> References: <20140129081156.GW2834@localhost.localdomain> <20140203124051.GC16123@localhost.localdomain> Message-ID: Yes it works if I specify the -s as ldap.mycorp.com. So we have progress! It now appears to authenticate fine when it posts the session but I have a new error. I get an Ipa Error 911 "Missing HTTP referer.
You have to configure your browser to send HTTP referer header." I assume this is because the external name doesn't match the internal name. Is there a way to modify this somewhere? Thanks. Steve On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose wrote: > On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote: > > Hi Sumit, That does indeed work. What does that tell us? > > I'm sorry, but it only tells that in general GSSAPI/Kerberos is working. > I think it does not help much with your original issue. About > ipa-getkeytab, does it work if you specify the server with the > -s/--server option? > > > bye, > Sumit > > > > > Steve > > > > > > On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose wrote: > > > > > On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: > > > > Hi Everyone, > > > > > > > > I have deployed freeipa inside our production network. I want to be > able > > > to > > > > access the web ui so I am attempting to add it to our nginx edge > > > machine. I > > > > can pass the requests upstream just fine but I am unable to login > using a > > > > username/password. I have enabled password authentication in the > kerberos > > > > section of the freeipa httpd config file. In the logs it looks like > the > > > > authentication succeeds and a ticket is issued. I assume that the > cookie > > > > that is returned (ipa_session) has the authentication information in > it. > > > > The subsequent call to get json data fails and I am prompted to login > > > again. > > > > > > > > I found this thread ( > > > > > https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) > > > > which has instructions on adding ipa.mydomain.com to the keytab. > When I > > > > call ipa-getkeytab it hangs for a bit before returning: > > > ldap_sasl_bind(SIMPLE): > > > > Can't contact LDAP server (-1) > > > > > > > > Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// > > > ldap.mydomain.com > > > > > > > > I get: > > > > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > > > > additional info: SASL(-4): no mechanism available: > > > > > > Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y > > > GSSAPI ....' ? > > > > > > bye, > > > Sumit > > > > > > > > > > > So we seem to have a SASL problem. If I run ldapsearch with -x simple > > > > authentication works just fine. > > > > > > > > Do I need to do something special to enable SASL so I can get the > keytab? > > > > The ipa-getkeytab command does not seem to have an option to use > simple > > > > authentication. > > > > > > > > Thanks. > > > > > > > > Steve > > > > > > > _______________________________________________ > > > > Freeipa-users mailing list > > > > Freeipa-users at redhat.com > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- Steve Severance Director of Engineering Altos Research e. steve at altosresearch.com m. (240) 472 - 9645 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 3 19:10:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Feb 2014 21:10:32 +0200 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: References: <20140129081156.GW2834@localhost.localdomain> <20140203124051.GC16123@localhost.localdomain> Message-ID: <20140203191032.GA5946@redhat.com> On Mon, 03 Feb 2014, Steve Severance wrote: >Yes it works if I specify the -s as ldap.mycorp.com. So we have progress! >It now appears to authenticate fine when it posts the session but I have a >new error. > >I get an Ipa Error 911 "Missing HTTP referer.
You have to configure >your browser to send HTTP referer header." I assume this is because the >external name doesn't match the internal name. Is there a way to modify >this somewhere? You can read https://bugzilla.redhat.com/show_bug.cgi?id=747710 for details and https://rhn.redhat.com/errata/RHSA-2011-1533.html is the security errata addressing it. We are deliberately closing cross-site forgery by enforcing HTTP referrer checks. Your nginx proxy would be a middle man which we are attempting to protect against. Recent discussions on how to allow your use case but still keep the security tight can be seen here: http://comments.gmane.org/gmane.linux.redhat.freeipa.user/8920 (latter part of the thread). Discussion stalled since then. > >Thanks. > >Steve > > >On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose wrote: > >> On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote: >> > Hi Sumit, That does indeed work. What does that tell us? >> >> I'm sorry, but it only tells that in general GSSAPI/Kerberos is working. >> I think it does not help much with your original issue. About >> ipa-getkeytab, does it work if you specify the server with the >> -s/--server option? >> >> >> bye, >> Sumit >> >> > >> > Steve >> > >> > >> > On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose wrote: >> > >> > > On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: >> > > > Hi Everyone, >> > > > >> > > > I have deployed freeipa inside our production network. I want to be >> able >> > > to >> > > > access the web ui so I am attempting to add it to our nginx edge >> > > machine. I >> > > > can pass the requests upstream just fine but I am unable to login >> using a >> > > > username/password. I have enabled password authentication in the >> kerberos >> > > > section of the freeipa httpd config file. In the logs it looks like >> the >> > > > authentication succeeds and a ticket is issued. I assume that the >> cookie >> > > > that is returned (ipa_session) has the authentication information in >> it. >> > > > The subsequent call to get json data fails and I am prompted to login >> > > again. >> > > > >> > > > I found this thread ( >> > > > >> https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) >> > > > which has instructions on adding ipa.mydomain.com to the keytab. >> When I >> > > > call ipa-getkeytab it hangs for a bit before returning: >> > > ldap_sasl_bind(SIMPLE): >> > > > Can't contact LDAP server (-1) >> > > > >> > > > Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// >> > > ldap.mydomain.com >> > > > >> > > > I get: >> > > > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) >> > > > additional info: SASL(-4): no mechanism available: >> > > >> > > Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y >> > > GSSAPI ....' ? >> > > >> > > bye, >> > > Sumit >> > > >> > > > >> > > > So we seem to have a SASL problem. If I run ldapsearch with -x simple >> > > > authentication works just fine. >> > > > >> > > > Do I need to do something special to enable SASL so I can get the >> keytab? >> > > > The ipa-getkeytab command does not seem to have an option to use >> simple >> > > > authentication. >> > > > >> > > > Thanks. >> > > > >> > > > Steve >> > > >> > > > _______________________________________________ >> > > > Freeipa-users mailing list >> > > > Freeipa-users at redhat.com >> > > > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >> > > > >-- >Steve Severance >Director of Engineering >Altos Research > >e. steve at altosresearch.com >m. (240) 472 - 9645 >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- / Alexander Bokovoy From steve at altosresearch.com Mon Feb 3 22:10:43 2014 From: steve at altosresearch.com (Steve Severance) Date: Mon, 3 Feb 2014 14:10:43 -0800 Subject: [Freeipa-users] Deploying freeipa behind nginx In-Reply-To: <20140203191032.GA5946@redhat.com> References: <20140129081156.GW2834@localhost.localdomain> <20140203124051.GC16123@localhost.localdomain> <20140203191032.GA5946@redhat.com> Message-ID: So I understand the mitigation of CSRF attacks. I would like ipa to be able to handle a specific set of referers. My use case may be less common since my freeipa instance is handling our server infrastructure not desktops. I have everything working now. Here is an example nginx server config in case anyone else needs it: server { server_name ipa.corp.com; listen 443 ssl; location / { proxy_cookie_domain ldap.corp.com ipa.corp.com; proxy_pass https://ldap.corp.com/; proxy_set_header Referer https://ldap.corp.com/ipa/ui; } } ipa.corp.com would be the external server and ldap.corp.com would be the internal server. Thanks for your help. Steve On Mon, Feb 3, 2014 at 11:10 AM, Alexander Bokovoy wrote: > On Mon, 03 Feb 2014, Steve Severance wrote: > >> Yes it works if I specify the -s as ldap.mycorp.com. So we have progress! >> It now appears to authenticate fine when it posts the session but I have a >> new error. >> >> I get an Ipa Error 911 "Missing HTTP referer.
You have to configure >> your browser to send HTTP referer header." I assume this is because the >> external name doesn't match the internal name. Is there a way to modify >> this somewhere? >> > You can read https://bugzilla.redhat.com/show_bug.cgi?id=747710 for > details and https://rhn.redhat.com/errata/RHSA-2011-1533.html is the > security errata addressing it. > > We are deliberately closing cross-site forgery by enforcing > HTTP referrer checks. > > Your nginx proxy would be a middle man which we are attempting to > protect against. > > Recent discussions on how to allow your use case but still keep the > security tight can be seen here: > http://comments.gmane.org/gmane.linux.redhat.freeipa.user/8920 (latter > part of the thread). Discussion stalled since then. > > > >> Thanks. >> >> Steve >> >> >> On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose wrote: >> >> On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote: >>> > Hi Sumit, That does indeed work. What does that tell us? >>> >>> I'm sorry, but it only tells that in general GSSAPI/Kerberos is working. >>> I think it does not help much with your original issue. About >>> ipa-getkeytab, does it work if you specify the server with the >>> -s/--server option? >>> >>> >>> bye, >>> Sumit >>> >>> > >>> > Steve >>> > >>> > >>> > On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose wrote: >>> > >>> > > On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: >>> > > > Hi Everyone, >>> > > > >>> > > > I have deployed freeipa inside our production network. I want to be >>> able >>> > > to >>> > > > access the web ui so I am attempting to add it to our nginx edge >>> > > machine. I >>> > > > can pass the requests upstream just fine but I am unable to login >>> using a >>> > > > username/password. I have enabled password authentication in the >>> kerberos >>> > > > section of the freeipa httpd config file. In the logs it looks like >>> the >>> > > > authentication succeeds and a ticket is issued. I assume that the >>> cookie >>> > > > that is returned (ipa_session) has the authentication information >>> in >>> it. >>> > > > The subsequent call to get json data fails and I am prompted to >>> login >>> > > again. >>> > > > >>> > > > I found this thread ( >>> > > > >>> https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) >>> > > > which has instructions on adding ipa.mydomain.com to the keytab. >>> When I >>> > > > call ipa-getkeytab it hangs for a bit before returning: >>> > > ldap_sasl_bind(SIMPLE): >>> > > > Can't contact LDAP server (-1) >>> > > > >>> > > > Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// >>> > > ldap.mydomain.com >>> > > > >>> > > > I get: >>> > > > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) >>> > > > additional info: SASL(-4): no mechanism available: >>> > > >>> > > Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y >>> > > GSSAPI ....' ? >>> > > >>> > > bye, >>> > > Sumit >>> > > >>> > > > >>> > > > So we seem to have a SASL problem. If I run ldapsearch with -x >>> simple >>> > > > authentication works just fine. >>> > > > >>> > > > Do I need to do something special to enable SASL so I can get the >>> keytab? >>> > > > The ipa-getkeytab command does not seem to have an option to use >>> simple >>> > > > authentication. >>> > > > >>> > > > Thanks. >>> > > > >>> > > > Steve >>> > > >>> > > > _______________________________________________ >>> > > > Freeipa-users mailing list >>> > > > Freeipa-users at redhat.com >>> > > > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > > >>> >>> >> >> >> -- >> Steve Severance >> Director of Engineering >> Altos Research >> >> e. steve at altosresearch.com >> m. (240) 472 - 9645 >> > > _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > -- > / Alexander Bokovoy > -- Steve Severance Director of Engineering Altos Research e. steve at altosresearch.com m. (240) 472 - 9645 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Tue Feb 4 04:11:12 2014 From: Less at imagine-sw.com (Les Stott) Date: Tue, 4 Feb 2014 04:11:12 +0000 Subject: [Freeipa-users] HBAC - expected behaviour? Message-ID: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host "host1" and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all : all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Tue Feb 4 05:37:03 2014 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 4 Feb 2014 05:37:03 +0000 Subject: [Freeipa-users] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past Message-ID: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> If you are seeing clock skew errors in /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you will need to verify the time/date of the server to make sure NTP isn't freaked out. If the system date is correct, it is possible that the change number generator has skewed. [01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 repl="dc=example,dc=com": Excessive clock skew from supplier RUV [01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit exceeded; value - 1448518, limit - 86400 [01/Feb/2014:14:42:06 -0800] - CSN generator's state: [01/Feb/2014:14:42:06 -0800] - replica id: 115 [01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526 [01/Feb/2014:14:42:06 -0800] - local offset: 0 [01/Feb/2014:14:42:06 -0800] - remote offset: 0 [01/Feb/2014:14:42:06 -0800] - sequence number: 55067 The following NsState_Script should be used to determine whether the change number generator has jumped significantly from the real time/date. https://github.com/richm/scripts/blob/master/readNsState.py The usage for the script works like this: [root at ipaserver.ops jaquino]# ./readNsState.py /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif nsState is cwAAAAAAAABGPfBSAAAAAAAAAAAAAAAAAQAAAAAAAAACAAAAAAAAAA== Little Endian For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 115 Sampled Time : 1391476038 Gen as csn : 52f03d46000201150000 Time as str : Mon Feb 3 17:07:18 2014 Local Offset : 0 Remote Offset : 1 Seq. num : 2 System time : Mon Feb 3 17:09:11 2014 Diff in sec. : 113 Day:sec diff : 0:113 If the output from the above command is over a day or more out of sync, then the reason is because the CSN generator has become grossly skewed. It will be necessary to perform the following steps to recover. -------------------------------------------- How to resolve this issue ? 1: Select an ipa server to be authoritative and write the contents of its database to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -a /tmp/master-389.ldif Note that without the -r option it is deliberately ommiting the tainted replication data which contains the bad CSNs ? 2: On the ipa server, shutdown its dirsrv daemon down so that you can reset the attribute responsible for the serial generation, and so that you can re-initialize its db from the known good ldif On the master supplier: ipactl stop ? 3: Sanitize the dse.ldif Configuration File On the master supplier: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== Delete the entire line ? 3.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif backup the old dse.ldif and replace it with the new one: # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif ? 4: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the master supplier: chmod 644 /tmp/master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/master-389.ldif ? 5: Restart the ipa daemons on the master supplier #ipactl start ? 6: When the daemon starts, it will see that it does not have an nsState and will write new CSN's to -all- of the newly imported good data with today's timetamp, we need to take that data and write -it- out to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif ^ the -r tells it to include all replica data which includes the newly blessed CSN data transfer the file to all of the ipa servers in the fleet ? 7: Now we must re-initialize _every other_ ipa consumer server in the fleet with the new good data. Steps 7-10 need to be done 1 at a time on each ipa consumer server ipactl stop ? 8: Sanitize the dse.ldif Configuration File On the ipa server: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== Delete the entire line ? 8.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif backup the old dse.ldif and replace it with the new one # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif ? 9: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the auth server: chmod 644 /tmp/replication-master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/replication-master-389.ldif ? 10: Restart the ipa daemons on the ipa server On the ipa server: ipactl start -------------------------------- From Rich Megginson: Further reading for those interested in the particulars of CSN tracking or the MultiMaster Replication algorithm, you can read up about it here: It all starts with the Leslie Lamport paper: http://www.stanford.edu/class/cs240/readings/lamport.pdf "Time, Clocks, and the Ordering of Events in a Distributed System" The next big impact on MMR protocols was the work done at Xerox PARC on the Bayou project. These and other sources formed the basis of the IETF LDUP working group. Much of the MMR protocol is based on the LDUP work. The tl;dr version is this: The MMR protocol is based on ordering operations by time so that when you have two updates to the same attribute, the "last one wins" So how do you guarantee some sort of consistent ordering throughout many systems that do not have clocks in sync down to the millisecond? If you say "ntp" then you lose... The protocol itself has to have some notion of time differences among servers The ordering is done by CSN (Change Sequence Number) The first part of the CSN is the timestamp of the operation in unix time_t (number of seconds since the epoch). In order to guarantee ordering, the MMR protocol has a major constraint You must never, never, issue a CSN that is the same or less than another CSN In order to guarantee that, the MMR protocol keeps track of the time differences among _all_ of the servers that it knows about. When it generates CSNs, it uses the largest time difference among all servers that it knows about. So how does the time skew grow at all? Due to timing differences, network latency, etc. the directory server cannot always generate the absolute exact system time. There will always be 1 or 2 second differences in some replication sessions. These 1 to 2 second differences accumulate over time. However, there are things which can introduce really large differences 1) buggy ntp implementations 2) bad sysadmin screws up the system clock 3) vms which are notorious for having laggy system clocks, etc. How can you monitor for this in the future? The readnsState.py script supplied in this email can be used to output the effective skew of the system date vs the CSN generator. You can set a crontab to run this script and monitor its output to catch any future severe drifts. Ticket information for some of the fixes that have been implimented because of this work so far: https://fedorahosted.org/389/ticket/47516 "You cannot hope to secure that which you do not first understand" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JR Aquino Senior Information Security Specialist, Technical Operations T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 GIAC Certified Exploit Researcher and Advanced Penetration Tester | GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler JR.Aquino at citrix.com Powering mobile workstyles and cloud services -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 15835 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mkosek at redhat.com Tue Feb 4 07:29:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Feb 2014 08:29:43 +0100 Subject: [Freeipa-users] HBAC - expected behaviour? In-Reply-To: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> Message-ID: <52F096E7.4090103@redhat.com> On 02/04/2014 05:11 AM, Les Stott wrote: > Hi, > > Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. > > I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. > > # ipa hbacrule-show host1_access > Rule name: host1_access > Description: Only john can access host1 > Enabled: TRUE > Users: john > Hosts: host1.domain.com > Services: sshd > > When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. > > If I access the host "host1" and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. > > # ipa hbacrule-show allow_all > Rule name: allow_all > User category: all > : all > Service category: all > Description: Allow all users to access any host from any host > Enabled: TRUE > Hosts: host2.domain.com, host3.domain.com, host4.domain.com > > Is this how its supposed to be? Or is it a bug in this older version? > I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. > > Thanks, > > Les Hello Les, I am not aware of any recent bugs in HBAC, this is likely a configuration issue. This is how the default HBAC allow_all looks like: # ipa hbacrule-show allow_all Rule name: allow_all User category: all Host category: all <---- : all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE "Host category: all" means that the rule is effective for all hosts. By selectively specifying the hosts, you disabled this selector. Does it help? Martin From tmaugh at boingo.com Tue Feb 4 17:04:06 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 17:04:06 +0000 Subject: [Freeipa-users] Creating password sync Message-ID: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 17:17:23 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 17:17:23 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local> also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 17:19:18 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 10:19:18 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local> Message-ID: <52F12116.2070304@redhat.com> On 02/04/2014 10:17 AM, Todd Maugh wrote: > also I have verified the password synchronization service is started > and running on the windows 2008 R2 server > > > but I cant tell if or what it is doing because iM not getting > passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Tuesday, February 04, 2014 9:04 AM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Creating password sync > > Ok, So I have my replication agreement set up. > > and I see accounts coming in to my IDM server from AD > > I have followed this guide from redhat > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html > > to set up my password sync. > > I get no errors > > but my passwords are not syncing! > > Help! the documentation tells o fno way to verify or trouble shoot > > > Thank You > > -Todd Maugh > tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Tue Feb 4 17:51:25 2014 From: mail at willsheldon.com (Will Sheldon) Date: Tue, 4 Feb 2014 09:51:25 -0800 Subject: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3) Message-ID: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. -- Kind regards, Will Sheldon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 19:56:24 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 19:56:24 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F12116.2070304@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:13:22 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:13:22 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C784@EXCHMB1-ELS.BWINC.local> now I am getting this after rerunning the install and trying to reinstall my cert LDAP bind error in connect 81: Can't Contact LDAP Server ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:20:08 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:20:08 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local> my passhook.log file is empty ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Tue Feb 4 20:28:42 2014 From: sdainard at miovision.com (Steve Dainard) Date: Tue, 4 Feb 2014 15:28:42 -0500 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: <52D9BFD7.30406@redhat.com> References: <52D9BFD7.30406@redhat.com> Message-ID: > > > > has anyone worked it out. Secondly cifs-utils has dependency on samba3 > packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like > each other , so this is the story of my experience with ipa. Any > suggestions ? > > > Why do you need cifs-utils on the same server? > cifs-utils to make a system a client to MSFT file server, AFAIU you cant > make IPA server to be a cifs client. > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html Step 3 mentions that cifs-utils is required, but: yum install cifs-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms | 3.7 kB 00:00 Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed --> Processing Dependency: libwbclient.so.0()(64bit) for package: cifs-utils-4.8.1-19.el6.x86_64 --> Running transaction check ---> Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be installed --> Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 --> Running transaction check ---> Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed --> Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: samba-winbind-3.6.9-167.el6_5.x86_64 --> Running transaction check ---> Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed --> Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-common < 3.9.9 --> Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind < 3.9.9 --> Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind-clients < 3.9.9 --> Finished Dependency Resolution Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 Error: samba4-winbind-clients conflicts with samba-winbind-clients-3.6.9-167.el6_5.x86_64 Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Is this no longer a requirement? Can this documentation be updated? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 20:40:29 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 13:40:29 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C784@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C784@EXCHMB1-ELS.BWINC.local> Message-ID: <52F1503D.4030903@redhat.com> On 02/04/2014 01:13 PM, Todd Maugh wrote: > now I am getting this after rerunning the install and trying to > reinstall my cert > > LDAP bind error in connect > 81: Can't Contact LDAP Server That means 1) ipa ldap server is down 2) some sort of network problem 3) incorrect host/port specified in passsync config 4) host specified in passsync config is not the FQDN, or the FQDN doesn't resolve both forward and reverse from the windows box 5) host specified in the passsync config does not match the ipa ldap server certificate subject dn 6) incorrect CA cert installed in passsync cert db > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Tuesday, February 04, 2014 11:56 AM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Creating password sync > > Im seeing these errors in the passsync.log > > 32: No such object > 02/03/14 16:23:40: Ldap error in QueryUsername > 32: No such object > 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired > 02/03/14 16:57:48: Ldap bind error in Connect > 32: No such object > 02/03/14 16:57:48: Ldap error in QueryUsername > 32: No such object > 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired > 02/03/14 18:06:04: Ldap bind error in Connect > 32: No such object > 02/04/14 10:24:59: PassSync service initialized > 02/04/14 10:24:59: PassSync service running > 02/04/14 10:25:00: Ldap bind error in Connect > 32: No such object > 02/04/14 10:58:37: Ldap bind error in Connect > 32: No such object > 02/04/14 10:58:37: PassSync service stopped > 02/04/14 10:58:38: PassSync service initialized > 02/04/14 10:58:38: PassSync service running > 02/04/14 10:58:39: Ldap bind error in Connect > 32: No such object > > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 9:19 AM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 10:17 AM, Todd Maugh wrote: >> also I have verified the password synchronization service is started >> and running on the windows 2008 R2 server >> >> >> but I cant tell if or what it is doing because iM not getting >> passwords to my IDM > http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging > > You can also look at the 389 access log to see if you have connections > from the windows box. > >> ------------------------------------------------------------------------ >> *From:* freeipa-users-bounces at redhat.com >> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >> [tmaugh at boingo.com] >> *Sent:* Tuesday, February 04, 2014 9:04 AM >> *To:* Rich Megginson; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* [Freeipa-users] Creating password sync >> >> Ok, So I have my replication agreement set up. >> >> and I see accounts coming in to my IDM server from AD >> >> I have followed this guide from redhat >> >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >> >> to set up my password sync. >> >> I get no errors >> >> but my passwords are not syncing! >> >> Help! the documentation tells o fno way to verify or trouble shoot >> >> >> Thank You >> >> -Todd Maugh >> tmaugh at boingo.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 20:40:51 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 13:40:51 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local> Message-ID: <52F15053.1060308@redhat.com> On 02/04/2014 01:20 PM, Todd Maugh wrote: > my passhook.log file is empty Have you changed any passwords in AD? > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Tuesday, February 04, 2014 11:56 AM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Creating password sync > > Im seeing these errors in the passsync.log > > 32: No such object > 02/03/14 16:23:40: Ldap error in QueryUsername > 32: No such object > 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired > 02/03/14 16:57:48: Ldap bind error in Connect > 32: No such object > 02/03/14 16:57:48: Ldap error in QueryUsername > 32: No such object > 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired > 02/03/14 18:06:04: Ldap bind error in Connect > 32: No such object > 02/04/14 10:24:59: PassSync service initialized > 02/04/14 10:24:59: PassSync service running > 02/04/14 10:25:00: Ldap bind error in Connect > 32: No such object > 02/04/14 10:58:37: Ldap bind error in Connect > 32: No such object > 02/04/14 10:58:37: PassSync service stopped > 02/04/14 10:58:38: PassSync service initialized > 02/04/14 10:58:38: PassSync service running > 02/04/14 10:58:39: Ldap bind error in Connect > 32: No such object > > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 9:19 AM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 10:17 AM, Todd Maugh wrote: >> also I have verified the password synchronization service is started >> and running on the windows 2008 R2 server >> >> >> but I cant tell if or what it is doing because iM not getting >> passwords to my IDM > http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging > > You can also look at the 389 access log to see if you have connections > from the windows box. > >> ------------------------------------------------------------------------ >> *From:* freeipa-users-bounces at redhat.com >> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >> [tmaugh at boingo.com] >> *Sent:* Tuesday, February 04, 2014 9:04 AM >> *To:* Rich Megginson; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* [Freeipa-users] Creating password sync >> >> Ok, So I have my replication agreement set up. >> >> and I see accounts coming in to my IDM server from AD >> >> I have followed this guide from redhat >> >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >> >> to set up my password sync. >> >> I get no errors >> >> but my passwords are not syncing! >> >> Help! the documentation tells o fno way to verify or trouble shoot >> >> >> Thank You >> >> -Todd Maugh >> tmaugh at boingo.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:42:08 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:42:08 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F15053.1060308@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local> I have not changed any passwords in AD yet. and the users I have in IDM from AD, their passwords are not working ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 20:45:30 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 13:45:30 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local> Message-ID: <52F1516A.1010709@redhat.com> On 02/04/2014 01:42 PM, Todd Maugh wrote: > I have not changed any passwords in AD yet. Then passsync will not have sent anything. > > and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 12:40 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 01:20 PM, Todd Maugh wrote: >> my passhook.log file is empty > > Have you changed any passwords in AD? > >> ------------------------------------------------------------------------ >> *From:* freeipa-users-bounces at redhat.com >> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >> [tmaugh at boingo.com] >> *Sent:* Tuesday, February 04, 2014 11:56 AM >> *To:* Rich Megginson; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] Creating password sync >> >> Im seeing these errors in the passsync.log >> >> 32: No such object >> 02/03/14 16:23:40: Ldap error in QueryUsername >> 32: No such object >> 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired >> 02/03/14 16:57:48: Ldap bind error in Connect >> 32: No such object >> 02/03/14 16:57:48: Ldap error in QueryUsername >> 32: No such object >> 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired >> 02/03/14 18:06:04: Ldap bind error in Connect >> 32: No such object >> 02/04/14 10:24:59: PassSync service initialized >> 02/04/14 10:24:59: PassSync service running >> 02/04/14 10:25:00: Ldap bind error in Connect >> 32: No such object >> 02/04/14 10:58:37: Ldap bind error in Connect >> 32: No such object >> 02/04/14 10:58:37: PassSync service stopped >> 02/04/14 10:58:38: PassSync service initialized >> 02/04/14 10:58:38: PassSync service running >> 02/04/14 10:58:39: Ldap bind error in Connect >> 32: No such object >> >> >> >> ------------------------------------------------------------------------ >> *From:* Rich Megginson [rmeggins at redhat.com] >> *Sent:* Tuesday, February 04, 2014 9:19 AM >> *To:* Todd Maugh; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: Creating password sync >> >> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>> also I have verified the password synchronization service is started >>> and running on the windows 2008 R2 server >>> >>> >>> but I cant tell if or what it is doing because iM not getting >>> passwords to my IDM >> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >> >> You can also look at the 389 access log to see if you have >> connections from the windows box. >> >>> ------------------------------------------------------------------------ >>> *From:* freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>> [tmaugh at boingo.com] >>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* [Freeipa-users] Creating password sync >>> >>> Ok, So I have my replication agreement set up. >>> >>> and I see accounts coming in to my IDM server from AD >>> >>> I have followed this guide from redhat >>> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>> >>> to set up my password sync. >>> >>> I get no errors >>> >>> but my passwords are not syncing! >>> >>> Help! the documentation tells o fno way to verify or trouble shoot >>> >>> >>> Thank You >>> >>> -Todd Maugh >>> tmaugh at boingo.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:48:03 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:48:03 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F1516A.1010709@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:53:23 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:53:23 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 20:57:02 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 20:57:02 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local> I tested a ssl connection from my ldap server to AD this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Tue Feb 4 20:59:44 2014 From: sdainard at miovision.com (Steve Dainard) Date: Tue, 4 Feb 2014 15:59:44 -0500 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) Message-ID: Following this guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html STEP 4: ipa-server-install --setup-dns -p '' -a '' -r MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux --forwarder=10.0.0.2 --forwarder=10.0.0.5 Server host name [ipa1.miovision.linux]: Warning: skipping DNS resolution of host ipa1.miovision.linux Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 10.0.6.3 Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [6.0.10.in-addr.arpa.]: Using reverse zone 6.0.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: ipa1.miovision.linux IP address: 10.0.6.3 Domain name: miovision.linux Realm name: MIOVISION.LINUX BIND DNS server will be configured to serve IPA domain with: Forwarders: 10.0.0.2, 10.0.0.5 Reverse zone: 6.0.10.in-addr.arpa. Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container Failed to initialize the realm container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 */var/log/ipaserver-install.log* add aci: (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux")(targetattr="userCertificate")(version 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux";) modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" modify complete 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) 2014-02-04T20:45:51Z DEBUG duration: 6 seconds 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal root/admin at MIOVISION.LINUX with password. 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the database while initializing kadmin.local interface 2014-02-04T20:45:51Z INFO File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1024, in main subject_base=options.subject) File "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", line 183, in create_instance self.start_creation(runtime=30) File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", line 386, in __create_ds_keytab installutils.kadmin_addprinc(ldap_principal) File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 369, in kadmin_addprinc kadmin("addprinc -randkey " + principal) File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 366, in kadmin "-x", "ipa-setup-override-restrictions"]) File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 316, in run raise CalledProcessError(p.returncode, args) 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, exception: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 21:00:55 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 14:00:55 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> Message-ID: <52F15507.402@redhat.com> On 02/04/2014 01:48 PM, Todd Maugh wrote: > but what about the "cant contact LDAP server in the passsync log" > LDAP bind error in connect > 81: Can't Contact LDAP Server That means 1) ipa ldap server is down 2) some sort of network problem 3) incorrect host/port specified in passsync config 4) host specified in passsync config is not the FQDN, or the FQDN doesn't resolve both forward and reverse from the windows box 5) host specified in the passsync config does not match the ipa ldap server certificate subject dn 6) incorrect CA cert installed in passsync cert db > > and are you saying I should try to change one of the passwords in AD > for it to go to IDM, or vice versa? In order for AD to send a password, you have to change a password in AD. When I said "This is one of the (many) problems with passsync", I meant that passsync will not sync existing passwords from AD to IdM. Passsync requires an AD password change operation in order to sync a password. If you were expecting that your existing AD passwords would just suddenly work in IdM, without having all of your AD users change their passwords, that's not how passsync works. There is no way to do that. This is but one of the reasons why the AD/IdM cross domain trust solution is preferred. When I said "This is one of the (many) problems with passsync", I most certainly did not mean that "LDAP bind error in connect > 81: Can't Contact LDAP Server" is one of the many problems. It is almost always a configuration issue. > > thanks > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 12:45 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 01:42 PM, Todd Maugh wrote: >> I have not changed any passwords in AD yet. > > Then passsync will not have sent anything. > >> >> and the users I have in IDM from AD, their passwords are not working > > Right. This is one of the (many) problems with the passsync approach > - there currently is no way to populate the initial passwords - that > is, passsync/IdM cannot copy your passwords over from AD to IdM. > >> >> >> ------------------------------------------------------------------------ >> *From:* Rich Megginson [rmeggins at redhat.com] >> *Sent:* Tuesday, February 04, 2014 12:40 PM >> *To:* Todd Maugh; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: Creating password sync >> >> On 02/04/2014 01:20 PM, Todd Maugh wrote: >>> my passhook.log file is empty >> >> Have you changed any passwords in AD? >> >>> ------------------------------------------------------------------------ >>> *From:* freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>> [tmaugh at boingo.com] >>> *Sent:* Tuesday, February 04, 2014 11:56 AM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] Creating password sync >>> >>> Im seeing these errors in the passsync.log >>> >>> 32: No such object >>> 02/03/14 16:23:40: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 16:57:48: Ldap bind error in Connect >>> 32: No such object >>> 02/03/14 16:57:48: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 18:06:04: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:24:59: PassSync service initialized >>> 02/04/14 10:24:59: PassSync service running >>> 02/04/14 10:25:00: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: PassSync service stopped >>> 02/04/14 10:58:38: PassSync service initialized >>> 02/04/14 10:58:38: PassSync service running >>> 02/04/14 10:58:39: Ldap bind error in Connect >>> 32: No such object >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rich Megginson [rmeggins at redhat.com] >>> *Sent:* Tuesday, February 04, 2014 9:19 AM >>> *To:* Todd Maugh; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: Creating password sync >>> >>> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>>> also I have verified the password synchronization service is >>>> started and running on the windows 2008 R2 server >>>> >>>> >>>> but I cant tell if or what it is doing because iM not getting >>>> passwords to my IDM >>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >>> >>> You can also look at the 389 access log to see if you have >>> connections from the windows box. >>> >>>> ------------------------------------------------------------------------ >>>> *From:* freeipa-users-bounces at redhat.com >>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>> [tmaugh at boingo.com] >>>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>>> *To:* Rich Megginson; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* [Freeipa-users] Creating password sync >>>> >>>> Ok, So I have my replication agreement set up. >>>> >>>> and I see accounts coming in to my IDM server from AD >>>> >>>> I have followed this guide from redhat >>>> >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>>> >>>> to set up my password sync. >>>> >>>> I get no errors >>>> >>>> but my passwords are not syncing! >>>> >>>> Help! the documentation tells o fno way to verify or trouble shoot >>>> >>>> >>>> Thank You >>>> >>>> -Todd Maugh >>>> tmaugh at boingo.com >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 21:01:31 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 14:01:31 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> Message-ID: <52F1552B.70708@redhat.com> On 02/04/2014 01:53 PM, Todd Maugh wrote: > I tried changing the password for a user in AD > > this is what the passsync log shows: > > 02/04/14 12:29:14: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:34: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:34: Ldap error in QueryUsername > 81: Can't contact LDAP server > 02/04/14 12:49:36: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:36: Ldap error in QueryUsername > 81: Can't contact LDAP server > > > and you say this is one of many issues with passsync. do you recommend > another option? > LDAP bind error in connect > 81: Can't Contact LDAP Server That means 1) ipa ldap server is down 2) some sort of network problem 3) incorrect host/port specified in passsync config 4) host specified in passsync config is not the FQDN, or the FQDN doesn't resolve both forward and reverse from the windows box 5) host specified in the passsync config does not match the ipa ldap server certificate subject dn 6) incorrect CA cert installed in passsync cert db In order for AD to send a password, you have to change a password in AD. When I said "This is one of the (many) problems with passsync", I meant that passsync will not sync existing passwords from AD to IdM. Passsync requires an AD password change operation in order to sync a password. If you were expecting that your existing AD passwords would just suddenly work in IdM, without having all of your AD users change their passwords, that's not how passsync works. There is no way to do that. This is but one of the reasons why the AD/IdM cross domain trust solution is preferred. When I said "This is one of the (many) problems with passsync", I most certainly did not mean that "LDAP bind error in connect > 81: Can't Contact LDAP Server" is one of the many problems. It is almost always a configuration issue. > > > ------------------------------------------------------------------------ > *From:* Todd Maugh > *Sent:* Tuesday, February 04, 2014 12:48 PM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* RE: Creating password sync > > but what about the "cant contact LDAP server in the passsync log" > > and are you saying I should try to change one of the passwords in AD > for it to go to IDM, or vice versa? > > thanks > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 12:45 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 01:42 PM, Todd Maugh wrote: >> I have not changed any passwords in AD yet. > > Then passsync will not have sent anything. > >> >> and the users I have in IDM from AD, their passwords are not working > > Right. This is one of the (many) problems with the passsync approach > - there currently is no way to populate the initial passwords - that > is, passsync/IdM cannot copy your passwords over from AD to IdM. > >> >> >> ------------------------------------------------------------------------ >> *From:* Rich Megginson [rmeggins at redhat.com] >> *Sent:* Tuesday, February 04, 2014 12:40 PM >> *To:* Todd Maugh; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: Creating password sync >> >> On 02/04/2014 01:20 PM, Todd Maugh wrote: >>> my passhook.log file is empty >> >> Have you changed any passwords in AD? >> >>> ------------------------------------------------------------------------ >>> *From:* freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>> [tmaugh at boingo.com] >>> *Sent:* Tuesday, February 04, 2014 11:56 AM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] Creating password sync >>> >>> Im seeing these errors in the passsync.log >>> >>> 32: No such object >>> 02/03/14 16:23:40: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 16:57:48: Ldap bind error in Connect >>> 32: No such object >>> 02/03/14 16:57:48: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 18:06:04: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:24:59: PassSync service initialized >>> 02/04/14 10:24:59: PassSync service running >>> 02/04/14 10:25:00: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: PassSync service stopped >>> 02/04/14 10:58:38: PassSync service initialized >>> 02/04/14 10:58:38: PassSync service running >>> 02/04/14 10:58:39: Ldap bind error in Connect >>> 32: No such object >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rich Megginson [rmeggins at redhat.com] >>> *Sent:* Tuesday, February 04, 2014 9:19 AM >>> *To:* Todd Maugh; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: Creating password sync >>> >>> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>>> also I have verified the password synchronization service is >>>> started and running on the windows 2008 R2 server >>>> >>>> >>>> but I cant tell if or what it is doing because iM not getting >>>> passwords to my IDM >>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >>> >>> You can also look at the 389 access log to see if you have >>> connections from the windows box. >>> >>>> ------------------------------------------------------------------------ >>>> *From:* freeipa-users-bounces at redhat.com >>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>> [tmaugh at boingo.com] >>>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>>> *To:* Rich Megginson; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* [Freeipa-users] Creating password sync >>>> >>>> Ok, So I have my replication agreement set up. >>>> >>>> and I see accounts coming in to my IDM server from AD >>>> >>>> I have followed this guide from redhat >>>> >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>>> >>>> to set up my password sync. >>>> >>>> I get no errors >>>> >>>> but my passwords are not syncing! >>>> >>>> Help! the documentation tells o fno way to verify or trouble shoot >>>> >>>> >>>> Thank You >>>> >>>> -Todd Maugh >>>> tmaugh at boingo.com >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 21:02:05 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 14:02:05 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local> Message-ID: <52F1554D.2080600@redhat.com> On 02/04/2014 01:57 PM, Todd Maugh wrote: > I tested a ssl connection from my ldap server to AD Ok. What about the ssl connection from the windows AD machine to your IdM ldap server? > > this is the output > > openssl s_client -connect qatestdc2.boingoqa.local:636 > CONNECTED(00000003) > depth=0 > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 > verify error:num=27:certificate not trusted > verify return:1 > depth=0 > verify error:num=21:unable to verify the first certificate > verify return:1 > --- > Certificate chain > 0 s: > i:/DC=local/DC=boingoqa/CN=SKYWARPCA > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK > CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG > A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow > ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 > q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T > RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX > PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 > 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT > j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l > wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF > oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF > AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD > AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG > CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj > gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE > MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy > LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD > Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl > UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q > b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D > Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO > PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ > Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo > b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i > b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 > Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB > ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI > TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 > mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY > TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz > eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 > Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP > lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N > B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb > nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 > 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 > -----END CERTIFICATE----- > subject= > issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA > --- > Acceptable client certificate CA names > > /DC=local/DC=boingoqa/CN=SKYWARPCA > /CN=QATESTDC2.boingoqa.local > /DC=local/DC=boingoqa/CN=boingoqaca > /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA > /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 > /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority > /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) > /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA > /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root > /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA > /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA > /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > /O=BOINGO.COM/CN=Certificate Authority > /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority > /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority > /CN=NT AUTHORITY > --- > SSL handshake has read 3480 bytes and written 601 bytes > --- > New, TLSv1/SSLv3, Cipher is AES128-SHA > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1 > Cipher : AES128-SHA > Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A > Session-ID-ctx: > Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 > Key-Arg : None > Krb5 Principal: None > PSK identity: None > PSK identity hint: None > Start Time: 1391547347 > Timeout : 300 (sec) > Verify return code: 21 (unable to verify the first certificate) > --- > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Tuesday, February 04, 2014 12:53 PM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Creating password sync > > I tried changing the password for a user in AD > > this is what the passsync log shows: > > 02/04/14 12:29:14: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:34: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:34: Ldap error in QueryUsername > 81: Can't contact LDAP server > 02/04/14 12:49:36: Ldap bind error in Connect > 81: Can't contact LDAP server > 02/04/14 12:49:36: Ldap error in QueryUsername > 81: Can't contact LDAP server > > > and you say this is one of many issues with passsync. do you recommend > another option? > > > ------------------------------------------------------------------------ > *From:* Todd Maugh > *Sent:* Tuesday, February 04, 2014 12:48 PM > *To:* Rich Megginson; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* RE: Creating password sync > > but what about the "cant contact LDAP server in the passsync log" > > and are you saying I should try to change one of the passwords in AD > for it to go to IDM, or vice versa? > > thanks > > > ------------------------------------------------------------------------ > *From:* Rich Megginson [rmeggins at redhat.com] > *Sent:* Tuesday, February 04, 2014 12:45 PM > *To:* Todd Maugh; dpal at redhat.com > *Cc:* freeipa-users at redhat.com > *Subject:* Re: Creating password sync > > On 02/04/2014 01:42 PM, Todd Maugh wrote: >> I have not changed any passwords in AD yet. > > Then passsync will not have sent anything. > >> >> and the users I have in IDM from AD, their passwords are not working > > Right. This is one of the (many) problems with the passsync approach > - there currently is no way to populate the initial passwords - that > is, passsync/IdM cannot copy your passwords over from AD to IdM. > >> >> >> ------------------------------------------------------------------------ >> *From:* Rich Megginson [rmeggins at redhat.com] >> *Sent:* Tuesday, February 04, 2014 12:40 PM >> *To:* Todd Maugh; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: Creating password sync >> >> On 02/04/2014 01:20 PM, Todd Maugh wrote: >>> my passhook.log file is empty >> >> Have you changed any passwords in AD? >> >>> ------------------------------------------------------------------------ >>> *From:* freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>> [tmaugh at boingo.com] >>> *Sent:* Tuesday, February 04, 2014 11:56 AM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] Creating password sync >>> >>> Im seeing these errors in the passsync.log >>> >>> 32: No such object >>> 02/03/14 16:23:40: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 16:57:48: Ldap bind error in Connect >>> 32: No such object >>> 02/03/14 16:57:48: Ldap error in QueryUsername >>> 32: No such object >>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff >>> expired >>> 02/03/14 18:06:04: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:24:59: PassSync service initialized >>> 02/04/14 10:24:59: PassSync service running >>> 02/04/14 10:25:00: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: Ldap bind error in Connect >>> 32: No such object >>> 02/04/14 10:58:37: PassSync service stopped >>> 02/04/14 10:58:38: PassSync service initialized >>> 02/04/14 10:58:38: PassSync service running >>> 02/04/14 10:58:39: Ldap bind error in Connect >>> 32: No such object >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rich Megginson [rmeggins at redhat.com] >>> *Sent:* Tuesday, February 04, 2014 9:19 AM >>> *To:* Todd Maugh; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: Creating password sync >>> >>> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>>> also I have verified the password synchronization service is >>>> started and running on the windows 2008 R2 server >>>> >>>> >>>> but I cant tell if or what it is doing because iM not getting >>>> passwords to my IDM >>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >>> >>> You can also look at the 389 access log to see if you have >>> connections from the windows box. >>> >>>> ------------------------------------------------------------------------ >>>> *From:* freeipa-users-bounces at redhat.com >>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>> [tmaugh at boingo.com] >>>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>>> *To:* Rich Megginson; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* [Freeipa-users] Creating password sync >>>> >>>> Ok, So I have my replication agreement set up. >>>> >>>> and I see accounts coming in to my IDM server from AD >>>> >>>> I have followed this guide from redhat >>>> >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>>> >>>> to set up my password sync. >>>> >>>> I get no errors >>>> >>>> but my passwords are not syncing! >>>> >>>> Help! the documentation tells o fno way to verify or trouble shoot >>>> >>>> >>>> Thank You >>>> >>>> -Todd Maugh >>>> tmaugh at boingo.com >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 21:14:26 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 21:14:26 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F1554D.2080600@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <52F1554D.2080600@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226CACA@EXCHMB1-ELS.BWINC.local> trying to find a command to check that connection ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 1:02 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:57 PM, Todd Maugh wrote: I tested a ssl connection from my ldap server to AD Ok. What about the ssl connection from the windows AD machine to your IdM ldap server? this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 21:23:34 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 21:23:34 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F1554D.2080600@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <52F1554D.2080600@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226CB85@EXCHMB1-ELS.BWINC.local> Ok. What about the ssl connection from the windows AD machine to your IdM ldap server? ld = ldap_sslinit("se-idm-01.boingo.com:636", 389, 1); Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3); Error 0 = ldap_connect(hLdap, NULL); Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv); Host supports SSL, SSL cipher strength = 256 bits Established connection to se-idm-01.boingo.com:636. Retrieving base DSA information... Getting 1 entries: Dn: (RootDSE) dataversion: 020140131234000; defaultnamingcontext: dc=boingo,dc=com; lastusn: 5177; namingContexts: dc=boingo,dc=com; netscapemdsuffix: cn=ldap://dc=se-idm-01,dc=boingo,dc=com:389; objectClass: top; supportedControl (21): 2.16.840.1.113730.3.4.2; 2.16.840.1.113730.3.4.3; 2.16.840.1.113730.3.4.4; 2.16.840.1.113730.3.4.5; 1.2.840.113556.1.4.473 = ( SORT ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.16; 2.16.840.1.113730.3.4.15; 2.16.840.1.113730.3.4.17; 2.16.840.1.113730.3.4.19; 1.3.6.1.4.1.42.2.27.8.5.1; 1.3.6.1.4.1.42.2.27.9.5.2; 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.3.6.1.4.1.42.2.27.9.5.8; 1.3.6.1.4.1.4203.666.5.16; 2.16.840.1.113730.3.4.14; 2.16.840.1.113730.3.4.20; 1.3.6.1.4.1.1466.29539.12; 2.16.840.1.113730.3.4.12; 2.16.840.1.113730.3.4.18; 2.16.840.1.113730.3.4.13; supportedExtension (17): 2.16.840.1.113730.3.5.7; 2.16.840.1.113730.3.5.8; 2.16.840.1.113730.3.5.10; 2.16.840.1.113730.3.8.10.3; 1.3.6.1.4.1.4203.1.11.1; 2.16.840.1.113730.3.8.10.1; 2.16.840.1.113730.3.5.3; 2.16.840.1.113730.3.5.12; 2.16.840.1.113730.3.5.5; 2.16.840.1.113730.3.5.6; 2.16.840.1.113730.3.5.9; 2.16.840.1.113730.3.5.4; 2.16.840.1.113730.3.6.5; 2.16.840.1.113730.3.6.6; 2.16.840.1.113730.3.6.7; 2.16.840.1.113730.3.6.8; 1.3.6.1.4.1.1466.20037 = ( START_TLS ); supportedLDAPVersion (2): 2; 3; supportedSASLMechanisms (7): EXTERNAL; ANONYMOUS; PLAIN; LOGIN; DIGEST-MD5; GSSAPI; CRAM-MD5; vendorName: 389 Project; vendorVersion: 389-Directory/1.2.11.15 B2013.337.1530; this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From maleko42 at gmail.com Tue Feb 4 21:26:33 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Tue, 4 Feb 2014 16:26:33 -0500 Subject: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain Message-ID: I'm trying to configure our CentOS IPA Client for Single Sign On from our trusted AD domain. SSO works fine when I ssh to the IPA server, but not to the CentOS Client. It prompts for password which it accepts, so it's getting the authentication from the AD domain. Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local Anybody run into this? Suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 21:33:34 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 14:33:34 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226CB85@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <52F1554D.2080600@redhat.com> <6FB698E172A95F49BE009B36D56F53E226CB85@EXCHMB1-ELS.BWINC.local> Message-ID: <52F15CAE.1040503@redhat.com> On 02/04/2014 02:23 PM, Todd Maugh wrote: > > Ok. What about the ssl connection from the windows AD machine to your > IdM ldap server? > > > > ld = ldap_sslinit("se-idm-01.boingo.com:636 > ", 389, 1); > Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3); > Error 0 = ldap_connect(hLdap, NULL); > Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv); How did you specify the CA cert of the CA that issued the IdM ldap server cert? How did you specify that you want to check to see if the server FQDN is the same as the cn in the IdM ldap server cert subject DN? > Host supports SSL, SSL cipher strength = 256 bits > Established connection to se-idm-01.boingo.com:636 > . > Retrieving base DSA information... > Getting 1 entries: > Dn: (RootDSE) > dataversion: 020140131234000; > defaultnamingcontext: dc=boingo,dc=com; > lastusn: 5177; > namingContexts: dc=boingo,dc=com; > netscapemdsuffix: cn=ldap://dc=se-idm-01,dc=boingo,dc=com:389; > objectClass: top; > supportedControl (21): 2.16.840.1.113730.3.4.2; > 2.16.840.1.113730.3.4.3; 2.16.840.1.113730.3.4.4; > 2.16.840.1.113730.3.4.5; 1.2.840.113556.1.4.473 = ( SORT ); > 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.16; > 2.16.840.1.113730.3.4.15; 2.16.840.1.113730.3.4.17; > 2.16.840.1.113730.3.4.19; 1.3.6.1.4.1.42.2.27.8.5.1; > 1.3.6.1.4.1.42.2.27.9.5.2; 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); > 1.3.6.1.4.1.42.2.27.9.5.8; 1.3.6.1.4.1.4203.666.5.16; > 2.16.840.1.113730.3.4.14; 2.16.840.1.113730.3.4.20; > 1.3.6.1.4.1.1466.29539.12; 2.16.840.1.113730.3.4.12; > 2.16.840.1.113730.3.4.18; 2.16.840.1.113730.3.4.13; > supportedExtension (17): 2.16.840.1.113730.3.5.7; > 2.16.840.1.113730.3.5.8; 2.16.840.1.113730.3.5.10; > 2.16.840.1.113730.3.8.10.3; 1.3.6.1.4.1.4203.1.11.1; > 2.16.840.1.113730.3.8.10.1; 2.16.840.1.113730.3.5.3; > 2.16.840.1.113730.3.5.12; 2.16.840.1.113730.3.5.5; > 2.16.840.1.113730.3.5.6; 2.16.840.1.113730.3.5.9; > 2.16.840.1.113730.3.5.4; 2.16.840.1.113730.3.6.5; > 2.16.840.1.113730.3.6.6; 2.16.840.1.113730.3.6.7; > 2.16.840.1.113730.3.6.8; 1.3.6.1.4.1.1466.20037 = ( START_TLS ); > supportedLDAPVersion (2): 2; 3; > supportedSASLMechanisms (7): EXTERNAL; ANONYMOUS; PLAIN; LOGIN; > DIGEST-MD5; GSSAPI; CRAM-MD5; > vendorName: 389 Project; > vendorVersion: 389-Directory/1.2.11.15 B2013.337.1530; >> >> this is the output >> >> openssl s_client -connect qatestdc2.boingoqa.local:636 >> CONNECTED(00000003) >> depth=0 >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 >> verify error:num=27:certificate not trusted >> verify return:1 >> depth=0 >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> --- >> Certificate chain >> 0 s: >> i:/DC=local/DC=boingoqa/CN=SKYWARPCA >> --- >> Server certificate >> -----BEGIN CERTIFICATE----- >> MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK >> CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG >> A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow >> ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 >> q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T >> RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX >> PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 >> 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT >> j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l >> wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF >> oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF >> AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD >> AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG >> CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj >> gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE >> MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy >> LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD >> Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl >> UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q >> b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D >> Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO >> PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ >> Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo >> b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i >> b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 >> Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB >> ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI >> TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 >> mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY >> TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz >> eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 >> Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP >> lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N >> B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb >> nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 >> 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 >> -----END CERTIFICATE----- >> subject= >> issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA >> --- >> Acceptable client certificate CA names >> >> /DC=local/DC=boingoqa/CN=SKYWARPCA >> /CN=QATESTDC2.boingoqa.local >> /DC=local/DC=boingoqa/CN=boingoqaca >> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA >> /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 >> /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority >> /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) >> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA >> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root >> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA >> /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA >> /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >> /O=BOINGO.COM/CN=Certificate Authority >> /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority >> /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority >> /CN=NT AUTHORITY >> --- >> SSL handshake has read 3480 bytes and written 601 bytes >> --- >> New, TLSv1/SSLv3, Cipher is AES128-SHA >> Server public key is 2048 bit >> Secure Renegotiation IS supported >> Compression: NONE >> Expansion: NONE >> SSL-Session: >> Protocol : TLSv1 >> Cipher : AES128-SHA >> Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A >> Session-ID-ctx: >> Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 >> Key-Arg : None >> Krb5 Principal: None >> PSK identity: None >> PSK identity hint: None >> Start Time: 1391547347 >> Timeout : 300 (sec) >> Verify return code: 21 (unable to verify the first certificate) >> --- >> >> ------------------------------------------------------------------------ >> *From:* freeipa-users-bounces at redhat.com >> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >> [tmaugh at boingo.com] >> *Sent:* Tuesday, February 04, 2014 12:53 PM >> *To:* Rich Megginson; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] Creating password sync >> >> I tried changing the password for a user in AD >> >> this is what the passsync log shows: >> >> 02/04/14 12:29:14: Ldap bind error in Connect >> 81: Can't contact LDAP server >> 02/04/14 12:49:34: Ldap bind error in Connect >> 81: Can't contact LDAP server >> 02/04/14 12:49:34: Ldap error in QueryUsername >> 81: Can't contact LDAP server >> 02/04/14 12:49:36: Ldap bind error in Connect >> 81: Can't contact LDAP server >> 02/04/14 12:49:36: Ldap error in QueryUsername >> 81: Can't contact LDAP server >> >> >> and you say this is one of many issues with passsync. do you >> recommend another option? >> >> >> ------------------------------------------------------------------------ >> *From:* Todd Maugh >> *Sent:* Tuesday, February 04, 2014 12:48 PM >> *To:* Rich Megginson; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* RE: Creating password sync >> >> but what about the "cant contact LDAP server in the passsync log" >> >> and are you saying I should try to change one of the passwords in AD >> for it to go to IDM, or vice versa? >> >> thanks >> >> >> ------------------------------------------------------------------------ >> *From:* Rich Megginson [rmeggins at redhat.com] >> *Sent:* Tuesday, February 04, 2014 12:45 PM >> *To:* Todd Maugh; dpal at redhat.com >> *Cc:* freeipa-users at redhat.com >> *Subject:* Re: Creating password sync >> >> On 02/04/2014 01:42 PM, Todd Maugh wrote: >>> I have not changed any passwords in AD yet. >> >> Then passsync will not have sent anything. >> >>> >>> and the users I have in IDM from AD, their passwords are not working >> >> Right. This is one of the (many) problems with the passsync approach >> - there currently is no way to populate the initial passwords - that >> is, passsync/IdM cannot copy your passwords over from AD to IdM. >> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rich Megginson [rmeggins at redhat.com] >>> *Sent:* Tuesday, February 04, 2014 12:40 PM >>> *To:* Todd Maugh; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: Creating password sync >>> >>> On 02/04/2014 01:20 PM, Todd Maugh wrote: >>>> my passhook.log file is empty >>> >>> Have you changed any passwords in AD? >>> >>>> ------------------------------------------------------------------------ >>>> *From:* freeipa-users-bounces at redhat.com >>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>> [tmaugh at boingo.com] >>>> *Sent:* Tuesday, February 04, 2014 11:56 AM >>>> *To:* Rich Megginson; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* Re: [Freeipa-users] Creating password sync >>>> >>>> Im seeing these errors in the passsync.log >>>> >>>> 32: No such object >>>> 02/03/14 16:23:40: Ldap error in QueryUsername >>>> 32: No such object >>>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff >>>> expired >>>> 02/03/14 16:57:48: Ldap bind error in Connect >>>> 32: No such object >>>> 02/03/14 16:57:48: Ldap error in QueryUsername >>>> 32: No such object >>>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff >>>> expired >>>> 02/03/14 18:06:04: Ldap bind error in Connect >>>> 32: No such object >>>> 02/04/14 10:24:59: PassSync service initialized >>>> 02/04/14 10:24:59: PassSync service running >>>> 02/04/14 10:25:00: Ldap bind error in Connect >>>> 32: No such object >>>> 02/04/14 10:58:37: Ldap bind error in Connect >>>> 32: No such object >>>> 02/04/14 10:58:37: PassSync service stopped >>>> 02/04/14 10:58:38: PassSync service initialized >>>> 02/04/14 10:58:38: PassSync service running >>>> 02/04/14 10:58:39: Ldap bind error in Connect >>>> 32: No such object >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Rich Megginson [rmeggins at redhat.com] >>>> *Sent:* Tuesday, February 04, 2014 9:19 AM >>>> *To:* Todd Maugh; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* Re: Creating password sync >>>> >>>> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>>>> also I have verified the password synchronization service is >>>>> started and running on the windows 2008 R2 server >>>>> >>>>> >>>>> but I cant tell if or what it is doing because iM not getting >>>>> passwords to my IDM >>>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >>>> >>>> You can also look at the 389 access log to see if you have >>>> connections from the windows box. >>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* freeipa-users-bounces at redhat.com >>>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>>> [tmaugh at boingo.com] >>>>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>>>> *To:* Rich Megginson; dpal at redhat.com >>>>> *Cc:* freeipa-users at redhat.com >>>>> *Subject:* [Freeipa-users] Creating password sync >>>>> >>>>> Ok, So I have my replication agreement set up. >>>>> >>>>> and I see accounts coming in to my IDM server from AD >>>>> >>>>> I have followed this guide from redhat >>>>> >>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>>>> >>>>> to set up my password sync. >>>>> >>>>> I get no errors >>>>> >>>>> but my passwords are not syncing! >>>>> >>>>> Help! the documentation tells o fno way to verify or trouble shoot >>>>> >>>>> >>>>> Thank You >>>>> >>>>> -Todd Maugh >>>>> tmaugh at boingo.com >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 21:39:41 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 21:39:41 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <52F15CAE.1040503@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <52F1554D.2080600@redhat.com> <6FB698E172A95F49BE009B36D56F53E226CB85@EXCHMB1-ELS.BWINC.local>, <52F15CAE.1040503@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226CC4E@EXCHMB1-ELS.BWINC.local> How did you specify the CA cert of the CA that issued the IdM ldap server cert? On the AD server (qatestdc2) i downloaded the CA from the IDM server (se-idm-01) from the web url http://se-idm-01.boingo.com/ipa/config/ca.crt then I ran this cd "C:\Program Files\Red Hat Directory Password Synchronization" certutil.exe -d . -A -n "SE-IDM-01.BOINGO.com CA" -t CT,, -a -i IDMCA.crt How did you specify that you want to check to see if the server FQDN is the same as the cn in the IdM ldap server cert subject DN? I do not believe that I did this, as I am not sure how Host supports SSL, SSL cipher strength = 256 bits Established connection to se-idm-01.boingo.com:636. Retrieving base DSA information... Getting 1 entries: Dn: (RootDSE) dataversion: 020140131234000; defaultnamingcontext: dc=boingo,dc=com; lastusn: 5177; namingContexts: dc=boingo,dc=com; netscapemdsuffix: cn=ldap://dc=se-idm-01,dc=boingo,dc=com:389; objectClass: top; supportedControl (21): 2.16.840.1.113730.3.4.2; 2.16.840.1.113730.3.4.3; 2.16.840.1.113730.3.4.4; 2.16.840.1.113730.3.4.5; 1.2.840.113556.1.4.473 = ( SORT ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.16; 2.16.840.1.113730.3.4.15; 2.16.840.1.113730.3.4.17; 2.16.840.1.113730.3.4.19; 1.3.6.1.4.1.42.2.27.8.5.1; 1.3.6.1.4.1.42.2.27.9.5.2; 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.3.6.1.4.1.42.2.27.9.5.8; 1.3.6.1.4.1.4203.666.5.16; 2.16.840.1.113730.3.4.14; 2.16.840.1.113730.3.4.20; 1.3.6.1.4.1.1466.29539.12; 2.16.840.1.113730.3.4.12; 2.16.840.1.113730.3.4.18; 2.16.840.1.113730.3.4.13; supportedExtension (17): 2.16.840.1.113730.3.5.7; 2.16.840.1.113730.3.5.8; 2.16.840.1.113730.3.5.10; 2.16.840.1.113730.3.8.10.3; 1.3.6.1.4.1.4203.1.11.1; 2.16.840.1.113730.3.8.10.1; 2.16.840.1.113730.3.5.3; 2.16.840.1.113730.3.5.12; 2.16.840.1.113730.3.5.5; 2.16.840.1.113730.3.5.6; 2.16.840.1.113730.3.5.9; 2.16.840.1.113730.3.5.4; 2.16.840.1.113730.3.6.5; 2.16.840.1.113730.3.6.6; 2.16.840.1.113730.3.6.7; 2.16.840.1.113730.3.6.8; 1.3.6.1.4.1.1466.20037 = ( START_TLS ); supportedLDAPVersion (2): 2; 3; supportedSASLMechanisms (7): EXTERNAL; ANONYMOUS; PLAIN; LOGIN; DIGEST-MD5; GSSAPI; CRAM-MD5; vendorName: 389 Project; vendorVersion: 389-Directory/1.2.11.15 B2013.337.1530; this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Feb 4 21:42:12 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Feb 2014 14:42:12 -0700 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226CC4E@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <52F1554D.2080600@redhat.com> <6FB698E172A95F49BE009B36D56F53E226CB85@EXCHMB1-ELS.BWINC.local>, <52F15CAE.1040503@redhat.com> <6FB698E172A95F49BE009B36D56F53E226CC4E@EXCHMB1-ELS.BWINC.local> Message-ID: <52F15EB4.60307@redhat.com> On 02/04/2014 02:39 PM, Todd Maugh wrote: > > How did you specify the CA cert of the CA that issued the IdM ldap > server cert? > > On the AD server (qatestdc2) i downloaded the CA from the IDM server > (se-idm-01) from the web url > > http://se-idm-01.boingo.com/|ipa/config/ca.crt| > > then I ran this > cd "C:\Program Files\Red Hat Directory Password Synchronization" > > certutil.exe -d . -A -n "SE-IDM-01.BOINGO.com CA" -t CT,, -a -i IDMCA.crt > > How did you specify that you want to check to see if the server FQDN > is the same as the cn in the IdM ldap server cert subject DN? > > I do not believe that I did this, as I am not sure how For both of my questions, I meant - how did you do those in your LDAP client that you ran on AD? > >> Host supports SSL, SSL cipher strength = 256 bits >> Established connection to se-idm-01.boingo.com:636 >> . >> Retrieving base DSA information... >> Getting 1 entries: >> Dn: (RootDSE) >> dataversion: 020140131234000; >> defaultnamingcontext: dc=boingo,dc=com; >> lastusn: 5177; >> namingContexts: dc=boingo,dc=com; >> netscapemdsuffix: cn=ldap://dc=se-idm-01,dc=boingo,dc=com:389; >> objectClass: top; >> supportedControl (21): 2.16.840.1.113730.3.4.2; >> 2.16.840.1.113730.3.4.3; 2.16.840.1.113730.3.4.4; >> 2.16.840.1.113730.3.4.5; 1.2.840.113556.1.4.473 = ( SORT ); >> 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.16; >> 2.16.840.1.113730.3.4.15; 2.16.840.1.113730.3.4.17; >> 2.16.840.1.113730.3.4.19; 1.3.6.1.4.1.42.2.27.8.5.1; >> 1.3.6.1.4.1.42.2.27.9.5.2; 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); >> 1.3.6.1.4.1.42.2.27.9.5.8; 1.3.6.1.4.1.4203.666.5.16; >> 2.16.840.1.113730.3.4.14; 2.16.840.1.113730.3.4.20; >> 1.3.6.1.4.1.1466.29539.12; 2.16.840.1.113730.3.4.12; >> 2.16.840.1.113730.3.4.18; 2.16.840.1.113730.3.4.13; >> supportedExtension (17): 2.16.840.1.113730.3.5.7; >> 2.16.840.1.113730.3.5.8; 2.16.840.1.113730.3.5.10; >> 2.16.840.1.113730.3.8.10.3; 1.3.6.1.4.1.4203.1.11.1; >> 2.16.840.1.113730.3.8.10.1; 2.16.840.1.113730.3.5.3; >> 2.16.840.1.113730.3.5.12; 2.16.840.1.113730.3.5.5; >> 2.16.840.1.113730.3.5.6; 2.16.840.1.113730.3.5.9; >> 2.16.840.1.113730.3.5.4; 2.16.840.1.113730.3.6.5; >> 2.16.840.1.113730.3.6.6; 2.16.840.1.113730.3.6.7; >> 2.16.840.1.113730.3.6.8; 1.3.6.1.4.1.1466.20037 = ( START_TLS ); >> supportedLDAPVersion (2): 2; 3; >> supportedSASLMechanisms (7): EXTERNAL; ANONYMOUS; PLAIN; LOGIN; >> DIGEST-MD5; GSSAPI; CRAM-MD5; >> vendorName: 389 Project; >> vendorVersion: 389-Directory/1.2.11.15 >> B2013.337.1530; >>> >>> this is the output >>> >>> openssl s_client -connect qatestdc2.boingoqa.local:636 >>> CONNECTED(00000003) >>> depth=0 >>> verify error:num=20:unable to get local issuer certificate >>> verify return:1 >>> depth=0 >>> verify error:num=27:certificate not trusted >>> verify return:1 >>> depth=0 >>> verify error:num=21:unable to verify the first certificate >>> verify return:1 >>> --- >>> Certificate chain >>> 0 s: >>> i:/DC=local/DC=boingoqa/CN=SKYWARPCA >>> --- >>> Server certificate >>> -----BEGIN CERTIFICATE----- >>> MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK >>> CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG >>> A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow >>> ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 >>> q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T >>> RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX >>> PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 >>> 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT >>> j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l >>> wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF >>> oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF >>> AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD >>> AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG >>> CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj >>> gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE >>> MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy >>> LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD >>> Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl >>> UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q >>> b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D >>> Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO >>> PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ >>> Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo >>> b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i >>> b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 >>> Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB >>> ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI >>> TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 >>> mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY >>> TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz >>> eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 >>> Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP >>> lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N >>> B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb >>> nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 >>> 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 >>> -----END CERTIFICATE----- >>> subject= >>> issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA >>> --- >>> Acceptable client certificate CA names >>> >>> /DC=local/DC=boingoqa/CN=SKYWARPCA >>> /CN=QATESTDC2.boingoqa.local >>> /DC=local/DC=boingoqa/CN=boingoqaca >>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA >>> /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 >>> /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority >>> /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) >>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA >>> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root >>> /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA >>> /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA >>> /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >>> /O=BOINGO.COM/CN=Certificate Authority >>> /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority >>> /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority >>> /CN=NT AUTHORITY >>> --- >>> SSL handshake has read 3480 bytes and written 601 bytes >>> --- >>> New, TLSv1/SSLv3, Cipher is AES128-SHA >>> Server public key is 2048 bit >>> Secure Renegotiation IS supported >>> Compression: NONE >>> Expansion: NONE >>> SSL-Session: >>> Protocol : TLSv1 >>> Cipher : AES128-SHA >>> Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A >>> Session-ID-ctx: >>> Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 >>> Key-Arg : None >>> Krb5 Principal: None >>> PSK identity: None >>> PSK identity hint: None >>> Start Time: 1391547347 >>> Timeout : 300 (sec) >>> Verify return code: 21 (unable to verify the first certificate) >>> --- >>> >>> ------------------------------------------------------------------------ >>> *From:* freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>> [tmaugh at boingo.com] >>> *Sent:* Tuesday, February 04, 2014 12:53 PM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: [Freeipa-users] Creating password sync >>> >>> I tried changing the password for a user in AD >>> >>> this is what the passsync log shows: >>> >>> 02/04/14 12:29:14: Ldap bind error in Connect >>> 81: Can't contact LDAP server >>> 02/04/14 12:49:34: Ldap bind error in Connect >>> 81: Can't contact LDAP server >>> 02/04/14 12:49:34: Ldap error in QueryUsername >>> 81: Can't contact LDAP server >>> 02/04/14 12:49:36: Ldap bind error in Connect >>> 81: Can't contact LDAP server >>> 02/04/14 12:49:36: Ldap error in QueryUsername >>> 81: Can't contact LDAP server >>> >>> >>> and you say this is one of many issues with passsync. do you >>> recommend another option? >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Todd Maugh >>> *Sent:* Tuesday, February 04, 2014 12:48 PM >>> *To:* Rich Megginson; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* RE: Creating password sync >>> >>> but what about the "cant contact LDAP server in the passsync log" >>> >>> and are you saying I should try to change one of the passwords in AD >>> for it to go to IDM, or vice versa? >>> >>> thanks >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rich Megginson [rmeggins at redhat.com] >>> *Sent:* Tuesday, February 04, 2014 12:45 PM >>> *To:* Todd Maugh; dpal at redhat.com >>> *Cc:* freeipa-users at redhat.com >>> *Subject:* Re: Creating password sync >>> >>> On 02/04/2014 01:42 PM, Todd Maugh wrote: >>>> I have not changed any passwords in AD yet. >>> >>> Then passsync will not have sent anything. >>> >>>> >>>> and the users I have in IDM from AD, their passwords are not working >>> >>> Right. This is one of the (many) problems with the passsync >>> approach - there currently is no way to populate the initial >>> passwords - that is, passsync/IdM cannot copy your passwords over >>> from AD to IdM. >>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Rich Megginson [rmeggins at redhat.com] >>>> *Sent:* Tuesday, February 04, 2014 12:40 PM >>>> *To:* Todd Maugh; dpal at redhat.com >>>> *Cc:* freeipa-users at redhat.com >>>> *Subject:* Re: Creating password sync >>>> >>>> On 02/04/2014 01:20 PM, Todd Maugh wrote: >>>>> my passhook.log file is empty >>>> >>>> Have you changed any passwords in AD? >>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* freeipa-users-bounces at redhat.com >>>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>>> [tmaugh at boingo.com] >>>>> *Sent:* Tuesday, February 04, 2014 11:56 AM >>>>> *To:* Rich Megginson; dpal at redhat.com >>>>> *Cc:* freeipa-users at redhat.com >>>>> *Subject:* Re: [Freeipa-users] Creating password sync >>>>> >>>>> Im seeing these errors in the passsync.log >>>>> >>>>> 32: No such object >>>>> 02/03/14 16:23:40: Ldap error in QueryUsername >>>>> 32: No such object >>>>> 02/03/14 16:57:48: Abandoning password change for scottb, backoff >>>>> expired >>>>> 02/03/14 16:57:48: Ldap bind error in Connect >>>>> 32: No such object >>>>> 02/03/14 16:57:48: Ldap error in QueryUsername >>>>> 32: No such object >>>>> 02/03/14 18:06:04: Abandoning password change for scottb, backoff >>>>> expired >>>>> 02/03/14 18:06:04: Ldap bind error in Connect >>>>> 32: No such object >>>>> 02/04/14 10:24:59: PassSync service initialized >>>>> 02/04/14 10:24:59: PassSync service running >>>>> 02/04/14 10:25:00: Ldap bind error in Connect >>>>> 32: No such object >>>>> 02/04/14 10:58:37: Ldap bind error in Connect >>>>> 32: No such object >>>>> 02/04/14 10:58:37: PassSync service stopped >>>>> 02/04/14 10:58:38: PassSync service initialized >>>>> 02/04/14 10:58:38: PassSync service running >>>>> 02/04/14 10:58:39: Ldap bind error in Connect >>>>> 32: No such object >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Rich Megginson [rmeggins at redhat.com] >>>>> *Sent:* Tuesday, February 04, 2014 9:19 AM >>>>> *To:* Todd Maugh; dpal at redhat.com >>>>> *Cc:* freeipa-users at redhat.com >>>>> *Subject:* Re: Creating password sync >>>>> >>>>> On 02/04/2014 10:17 AM, Todd Maugh wrote: >>>>>> also I have verified the password synchronization service is >>>>>> started and running on the windows 2008 R2 server >>>>>> >>>>>> >>>>>> but I cant tell if or what it is doing because iM not getting >>>>>> passwords to my IDM >>>>> http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging >>>>> >>>>> You can also look at the 389 access log to see if you have >>>>> connections from the windows box. >>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* freeipa-users-bounces at redhat.com >>>>>> [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh >>>>>> [tmaugh at boingo.com] >>>>>> *Sent:* Tuesday, February 04, 2014 9:04 AM >>>>>> *To:* Rich Megginson; dpal at redhat.com >>>>>> *Cc:* freeipa-users at redhat.com >>>>>> *Subject:* [Freeipa-users] Creating password sync >>>>>> >>>>>> Ok, So I have my replication agreement set up. >>>>>> >>>>>> and I see accounts coming in to my IDM server from AD >>>>>> >>>>>> I have followed this guide from redhat >>>>>> >>>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html >>>>>> >>>>>> to set up my password sync. >>>>>> >>>>>> I get no errors >>>>>> >>>>>> but my passwords are not syncing! >>>>>> >>>>>> Help! the documentation tells o fno way to verify or trouble shoot >>>>>> >>>>>> >>>>>> Thank You >>>>>> >>>>>> -Todd Maugh >>>>>> tmaugh at boingo.com >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Feb 4 22:11:24 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 4 Feb 2014 22:11:24 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local> Message-ID: <3872ab9808f543e084f398348291bfcc@SINPR04MB298.apcprd04.prod.outlook.com> I am just doing this now and works fine for me. The password has to be changed as there is no way to de-crypt the password in AD and send that. So the .msi you install on each AD server intercepts the password change while its in "plain text" and sends it over to IPA, hence only changes. I did have issues with certs, they were a pain in the ass to get right/trusted, looks like you might have a similar issue. I had to work through Redhat support to get it right. On a brighter note I did it on RHEL6.4 and upgraded the IPA servers to RHEL6.5 and winsync and passync still work fine. I'll send you my notes. You could use trusts but frankly trusting AD with all its swiss cheese security seems a bit too risky. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Wednesday, 5 February 2014 9:57 a.m. To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tested a ssl connection from my ldap server to AD this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Tue Feb 4 22:13:38 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 4 Feb 2014 17:13:38 -0500 Subject: [Freeipa-users] Deny SSH access from selected host Message-ID: Hello I have an ipa-server-2.2.0-16.el6.x86_64 server serving different version of ipa-clients and so far it has been good. I have noticed that some of our DEVs have started to ssh into some of the systems that I had no intention of making available through ssh. I have tried to revoke specific group ssh permission from a certain host and I don't seem to be having luck. I have only looked under policy and IPA server tabs but these two tabs seem like they can only add more access/role from the default user. Would it be possible to deny ssh access per host without pulling a host off FreeIPA management? Thanks in advance William -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 4 22:15:11 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 4 Feb 2014 22:15:11 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <3872ab9808f543e084f398348291bfcc@SINPR04MB298.apcprd04.prod.outlook.com> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <3872ab9808f543e084f398348291bfcc@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E226CD0A@EXCHMB1-ELS.BWINC.local> I would be so grateful for your notes as it looks like im most likely having a cert issue as well I'm so damn close to having this thing working, (doesn't help to have your boss come by every 10 minutes) I understand the changes concept now, if I can just get it to work ________________________________ From: Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Tuesday, February 04, 2014 2:11 PM To: Todd Maugh; Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync I am just doing this now and works fine for me. The password has to be changed as there is no way to de-crypt the password in AD and send that. So the .msi you install on each AD server intercepts the password change while its in "plain text" and sends it over to IPA, hence only changes. I did have issues with certs, they were a pain in the ass to get right/trusted, looks like you might have a similar issue. I had to work through Redhat support to get it right. On a brighter note I did it on RHEL6.4 and upgraded the IPA servers to RHEL6.5 and winsync and passync still work fine. I'll send you my notes. You could use trusts but frankly trusting AD with all its swiss cheese security seems a bit too risky. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Wednesday, 5 February 2014 9:57 a.m. To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tested a ssl connection from my ldap server to AD this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Feb 4 22:18:03 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 4 Feb 2014 22:18:03 +0000 Subject: [Freeipa-users] Creating password sync In-Reply-To: <6FB698E172A95F49BE009B36D56F53E226CD0A@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E226C53C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C55B@EXCHMB1-ELS.BWINC.local>, <52F12116.2070304@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C75C@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E226C7E3@EXCHMB1-ELS.BWINC.local>, <52F15053.1060308@redhat.com> <6FB698E172A95F49BE009B36D56F53E226C8B7@EXCHMB1-ELS.BWINC.local>, <52F1516A.1010709@redhat.com>, <6FB698E172A95F49BE009B36D56F53E226C931@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C95F@EXCHMB1-ELS.BWINC.local>, <6FB698E172A95F49BE009B36D56F53E226C9C4@EXCHMB1-ELS.BWINC.local>, <3872ab9808f543e084f398348291bfcc@SINPR04MB298.apcprd04.prod.outlook.com>, <6FB698E172A95F49BE009B36D56F53E226CD0A@EXCHMB1-ELS.BWINC.local> Message-ID: <7d3b3542be144e80afe8b1ca478f8a5f@SINPR04MB298.apcprd04.prod.outlook.com> notes just sent regards Steven ________________________________ From: Todd Maugh Sent: Wednesday, 5 February 2014 11:15 a.m. To: Steven Jones; Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync I would be so grateful for your notes as it looks like im most likely having a cert issue as well I'm so damn close to having this thing working, (doesn't help to have your boss come by every 10 minutes) I understand the changes concept now, if I can just get it to work ________________________________ From: Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Tuesday, February 04, 2014 2:11 PM To: Todd Maugh; Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync I am just doing this now and works fine for me. The password has to be changed as there is no way to de-crypt the password in AD and send that. So the .msi you install on each AD server intercepts the password change while its in "plain text" and sends it over to IPA, hence only changes. I did have issues with certs, they were a pain in the ass to get right/trusted, looks like you might have a similar issue. I had to work through Redhat support to get it right. On a brighter note I did it on RHEL6.4 and upgraded the IPA servers to RHEL6.5 and winsync and passync still work fine. I'll send you my notes. You could use trusts but frankly trusting AD with all its swiss cheese security seems a bit too risky. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Todd Maugh Sent: Wednesday, 5 February 2014 9:57 a.m. To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tested a ssl connection from my ldap server to AD this is the output openssl s_client -connect qatestdc2.boingoqa.local:636 CONNECTED(00000003) depth=0 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 verify error:num=27:certificate not trusted verify return:1 depth=0 verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s: i:/DC=local/DC=boingoqa/CN=SKYWARPCA --- Server certificate -----BEGIN CERTIFICATE----- MIIGpzCCBI+gAwIBAgIKYTm2iQAAAAAAETANBgkqhkiG9w0BAQQFADBFMRUwEwYK CZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghib2luZ29xYTESMBAG A1UEAxMJU0tZV0FSUENBMB4XDTE0MDIwNDE5MTcxNVoXDTE2MDIwNDE5MjcxNVow ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMBobXktKGUg/ynXMuQ7 q4KPRHSQkU7yD6wrpC+rzbjVYyg3LyE7+STlt0TbsataBciq5DExeByJIWvDn81T RW2dqXYUhCPfH96rt6SpnZtWwLs2fBtFqnC4K7Wf7k3b3JHUiMw+V9Q6Nlo4w6HX PygYAKVp/4L+SS0S55MRRYhTPgwE6nnj1HXbJuAwyNcn/xaqI5XIoSVYwXYNkaz5 4JibJ/bJvMqwfnIQH6JuTz2YgXSdebz6UzgsloYfJlpr15UoAvkRcjtdCN+I6ZGT j9AJNhOCzqDn1M5nrwpDj6+AZjf49yXQ4MndZaCAcD3lUIZZfzBh8plBIhbR6P9l wgsCAwEAAaOCAtwwggLYMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIb+j0KF oOMAh/2TOIWXwCKG2tdBgUiB4aFdg/6GFQIBZQIBADAyBgNVHSUEKzApBgcrBgEF AgMFBgorBgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQD AgWgMEAGCSsGAQQBgjcVCgQzMDEwCQYHKwYBBQIDBTAMBgorBgEEAYI3FAICMAoG CCsGAQUFBwMBMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQ7uvQtzIM4rIkZ+9gx+qwj gGfVVTAfBgNVHSMEGDAWgBR8X3Ffa9ODPVuv2VSdfoixzqhcgzCBzAYDVR0fBIHE MIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1TS1lXQVJQQ0EsQ049UUFURVNUREMy LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWJvaW5nb3FhLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCBvgYIKwYBBQUHAQEEgbEwga4wgasGCCsGAQUFBzAChoGebGRhcDovLy9D Tj1TS1lXQVJQQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Ym9pbmdvcWEsREM9bG9jYWw/ Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwQAYDVR0RAQH/BDYwNIIYUUFURVNUREMyLmJvaW5nb3FhLmxvY2Fsgg5i b2luZ29xYS5sb2NhbIIIQk9JTkdPUUEwDQYJKoZIhvcNAQEEBQADggIBALZdnAQ3 Q89udt97z7fRhCEOe/169M4Veo7mxw5IJ7/kdv3+6OQr/6xXOgy67SpeEj14BPCB ehEXHd1N8nSd5MxR73C65QxiC/jCR0VhHYIZyNkGke44EWl6o/7frHHXIkgKhSHI TumCdHc1erfwlRaifPksYO8f5HpE1FABeBhmPau003My4uLbcwMPt+XS1AlGSRM7 mxE3JjnFp0iD+kNvDA7SlcOYxkNRyCG1ty4TOdWq9FIRf9m+f4dLXZ/ZR2kPi7GY TBwCm4R8wqvi2UmNv2b/jhP39RqVEXMlFoVM2ciOSk5Za9zJ/0ykhHTImea92Pwz eNfF89abIR7rADkPsulcTfAuwLfHbnfB2DUw75WaIesNLyc49sjgWLSk2B0trjc8 Z2FiVWYRBgLLrn5OKOHIzBD9fuGShTMU5I6U53Sr0CtoSvAX57wfkSdlydAH/MqP lFBjzGWQA00ZiEgN0Cc1y47g50uHE8nUNoeVoxD0arBO8utvr7R6yL9caIvs+09N B/idR3c8Sjb0c3g8pCFGLzDkM6iH/cklzh8hYaddbCiHzDruzbJv4ORLFo7dL/Sb nZbit2qjoLUmnTSXAxE9A39qiX5f/cKUFnFB/kuiYKUoUFaWkLxmXd9zarIhkpA6 1adEmspCvWswrfVKhgrR1ELf4qNo1nEKOsi9 -----END CERTIFICATE----- subject= issuer=/DC=local/DC=boingoqa/CN=SKYWARPCA --- Acceptable client certificate CA names /DC=local/DC=boingoqa/CN=SKYWARPCA /CN=QATESTDC2.boingoqa.local /DC=local/DC=boingoqa/CN=boingoqaca /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /O=BOINGO.COM/CN=Certificate Authority /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY --- SSL handshake has read 3480 bytes and written 601 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 333C0000854E673466C6993943C1FBC7E65382AB7C486AFA750CB5F76D45302A Session-ID-ctx: Master-Key: 63BF2A0621C3438C7CD8A0037B3769FC9182FF517B7D07265B8EE5F74FD90BBA0B8E56B9F466F3502F32C816076DAA47 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1391547347 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 12:53 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync I tried changing the password for a user in AD this is what the passsync log shows: 02/04/14 12:29:14: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:34: Ldap error in QueryUsername 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap bind error in Connect 81: Can't contact LDAP server 02/04/14 12:49:36: Ldap error in QueryUsername 81: Can't contact LDAP server and you say this is one of many issues with passsync. do you recommend another option? ________________________________ From: Todd Maugh Sent: Tuesday, February 04, 2014 12:48 PM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: RE: Creating password sync but what about the "cant contact LDAP server in the passsync log" and are you saying I should try to change one of the passwords in AD for it to go to IDM, or vice versa? thanks ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:45 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:42 PM, Todd Maugh wrote: I have not changed any passwords in AD yet. Then passsync will not have sent anything. and the users I have in IDM from AD, their passwords are not working Right. This is one of the (many) problems with the passsync approach - there currently is no way to populate the initial passwords - that is, passsync/IdM cannot copy your passwords over from AD to IdM. ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 12:40 PM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 01:20 PM, Todd Maugh wrote: my passhook.log file is empty Have you changed any passwords in AD? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 11:56 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Creating password sync Im seeing these errors in the passsync.log 32: No such object 02/03/14 16:23:40: Ldap error in QueryUsername 32: No such object 02/03/14 16:57:48: Abandoning password change for scottb, backoff expired 02/03/14 16:57:48: Ldap bind error in Connect 32: No such object 02/03/14 16:57:48: Ldap error in QueryUsername 32: No such object 02/03/14 18:06:04: Abandoning password change for scottb, backoff expired 02/03/14 18:06:04: Ldap bind error in Connect 32: No such object 02/04/14 10:24:59: PassSync service initialized 02/04/14 10:24:59: PassSync service running 02/04/14 10:25:00: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: Ldap bind error in Connect 32: No such object 02/04/14 10:58:37: PassSync service stopped 02/04/14 10:58:38: PassSync service initialized 02/04/14 10:58:38: PassSync service running 02/04/14 10:58:39: Ldap bind error in Connect 32: No such object ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Tuesday, February 04, 2014 9:19 AM To: Todd Maugh; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: Creating password sync On 02/04/2014 10:17 AM, Todd Maugh wrote: also I have verified the password synchronization service is started and running on the windows 2008 R2 server but I cant tell if or what it is doing because iM not getting passwords to my IDM http://port389.org/wiki/Howto:WindowsSync#PassSync_Logging You can also look at the 389 access log to see if you have connections from the windows box. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Tuesday, February 04, 2014 9:04 AM To: Rich Megginson; dpal at redhat.com Cc: freeipa-users at redhat.com Subject: [Freeipa-users] Creating password sync Ok, So I have my replication agreement set up. and I see accounts coming in to my IDM server from AD I have followed this guide from redhat https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html to set up my password sync. I get no errors but my passwords are not syncing! Help! the documentation tells o fno way to verify or trouble shoot Thank You -Todd Maugh tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 5 07:39:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Feb 2014 09:39:27 +0200 Subject: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain In-Reply-To: References: Message-ID: <20140205073927.GF7586@redhat.com> On Tue, 04 Feb 2014, Mark Gardner wrote: >I'm trying to configure our CentOS IPA Client for Single Sign On from our >trusted AD domain. >SSO works fine when I ssh to the IPA server, but not to the CentOS Client. >It prompts for password which it accepts, so it's getting the >authentication from the AD domain. > >Fedora 20 IPA Server >CentOS 6.5 IPA Client >Win 2012 AD Domain Server > >Setup as IPA as a subdomain of AD. >AD Domain: test.local >IPA Domain: hosted.test.local > >Anybody run into this? Suggestions? Each client needs to be configured to accept AD users' SSO. Check that /etc/krb5.conf contains auth_to_local rules mapping principals from AD to their names as returned by SSSD. SSH daemon is picky about principal/name mapping. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Feb 5 07:43:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Feb 2014 09:43:55 +0200 Subject: [Freeipa-users] Deny SSH access from selected host In-Reply-To: References: Message-ID: <20140205074355.GG7586@redhat.com> On Tue, 04 Feb 2014, William Muriithi wrote: >Hello > >I have an ipa-server-2.2.0-16.el6.x86_64 server serving different version >of ipa-clients and so far it has been good. I have noticed that some of our >DEVs have started to ssh into some of the systems that I had no intention >of making available through ssh. > >I have tried to revoke specific group ssh permission from a certain host >and I don't seem to be having luck. I have only looked under policy and IPA >server tabs but these two tabs seem like they can only add more access/role >from the default user. > >Would it be possible to deny ssh access per host without pulling a host off >FreeIPA management? from-host part of the rule is not enforced by default due to the fact that it is pretty easy to fake that one on connection. You can try to create more specific rules allowing access to the systems. With allow_all rule disabled these would help -- when there is no rule for that user to access an SSH service on the host, it will not be able to do so. Are you using allow_all rule right now? http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- / Alexander Bokovoy From rcritten at redhat.com Wed Feb 5 09:35:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Feb 2014 10:35:12 +0100 Subject: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3) In-Reply-To: References: Message-ID: <52F205D0.3040300@redhat.com> Will Sheldon wrote: > > Hello IPA users :) > > We have implemented IPA using the packaged version in centos 6.5 (which > is 3.0.0-37.el6), but have been playing with the more recent version in > Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the > shiny new features, so are thinking about migrating. > > Has anyone done this? Is there an easy way to migrate/upgrade? > What would happen if I tried to setup a FC19 replica, would it get angry > and break? > > We only have users in production so far, (no production clients or > issued certs) so maybe the user migration script mentioned in previous > posts would be the best bet? > > Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob From rcritten at redhat.com Wed Feb 5 12:59:43 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Feb 2014 13:59:43 +0100 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) In-Reply-To: References: Message-ID: <52F235BF.6090705@redhat.com> Steve Dainard wrote: > Following this guide: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html > > STEP 4: > ipa-server-install --setup-dns -p '' -a '' -r > MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux > --forwarder=10.0.0.2 --forwarder=10.0.0.5 > > Server host name [ipa1.miovision.linux]: > > Warning: skipping DNS resolution of host ipa1.miovision.linux > Unable to resolve IP address for host name > Please provide the IP address to be used for this host name: 10.0.6.3 > Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name [6.0.10.in-addr.arpa.]: > Using reverse zone 6.0.10.in-addr.arpa. > > The IPA Master Server will be configured with: > Hostname: ipa1.miovision.linux > IP address: 10.0.6.3 > Domain name: miovision.linux > Realm name: MIOVISION.LINUX > > BIND DNS server will be configured to serve IPA domain with: > Forwarders: 10.0.0.2, 10.0.0.5 > Reverse zone: 6.0.10.in-addr.arpa. > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > > ... > > Done configuring directory server (dirsrv). > Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds > [1/10]: adding sasl mappings to the directory > [2/10]: adding kerberos container to the directory > [3/10]: configuring KDC > [4/10]: initialize kerberos container > Failed to initialize the realm container > [5/10]: adding default ACIs > [6/10]: creating a keytab for the directory > Unexpected error - see /var/log/ipaserver-install.log for details: > CalledProcessError: Command 'kadmin.local -q addprinc -randkey > ldap/ipa1.miovision.linux at MIOVISION.LINUX -x > ipa-setup-override-restrictions' returned non-zero exit status 1 > > */var/log/ipaserver-install.log* > > add aci: > > (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux")(targetattr="userCertificate")(version > 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = > "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux";) > modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" > modify complete > > > 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( > ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) > > 2014-02-04T20:45:51Z DEBUG duration: 6 seconds > 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory > 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey > ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override-restrictions > 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal > root/admin at MIOVISION.LINUX with password. > > 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the > database while initializing kadmin.local interface > > 2014-02-04T20:45:51Z INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1024, in main > subject_base=options.subject) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 183, in create_instance > self.start_creation(runtime=30) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 386, in __create_ds_keytab > installutils.kadmin_addprinc(ldap_principal) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 369, in kadmin_addprinc > kadmin("addprinc -randkey " + principal) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 366, in kadmin > "-x", "ipa-setup-override-restrictions"]) > > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line > 316, in run > raise CalledProcessError(p.returncode, args) > > 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, > exception: CalledProcessError: Command 'kadmin.local -q addprinc > -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x > ipa-setup-override-restrictions' returned non-zero exit status 1 > Hmm, strange. Nothing is jumping out at me for the cause or solution. What version of IPA is this? rpm -q ipa-server Any chance you can send the entire server install log? You can send it to me privately if you'd like. rob From maleko42 at gmail.com Wed Feb 5 14:27:00 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Wed, 5 Feb 2014 09:27:00 -0500 Subject: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain In-Reply-To: <20140205073927.GF7586@redhat.com> References: <20140205073927.GF7586@redhat.com> Message-ID: Thanks, That was what I missed. On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy wrote: > On Tue, 04 Feb 2014, Mark Gardner wrote: > >> I'm trying to configure our CentOS IPA Client for Single Sign On from our >> trusted AD domain. >> SSO works fine when I ssh to the IPA server, but not to the CentOS Client. >> It prompts for password which it accepts, so it's getting the >> authentication from the AD domain. >> >> Fedora 20 IPA Server >> CentOS 6.5 IPA Client >> Win 2012 AD Domain Server >> >> Setup as IPA as a subdomain of AD. >> AD Domain: test.local >> IPA Domain: hosted.test.local >> >> Anybody run into this? Suggestions? >> > Each client needs to be configured to accept AD users' SSO. > > Check that /etc/krb5.conf contains auth_to_local rules mapping principals > from > AD to their names as returned by SSSD. > > SSH daemon is picky about principal/name mapping. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Feb 5 15:24:12 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 05 Feb 2014 10:24:12 -0500 Subject: [Freeipa-users] Can't delete users Message-ID: <52F2579C.7070801@damascusgrp.com> We've discovered something odd in our current FreeIPA setup (F18, IPA 3.1.5-1.fc18.x86_64). Whenever we go to delete a user, the whole IPA infrastructure will hang. The web page becomes nonresponsive and the server doesn't respond to sudo or authentication requests. DNS requests go unanswered. The only solution we've found thus far is to "ipactl stop && ipactl start". Nothing ever shows up in any logfile we've looked at, presumably because whatever ought to be logging an error is hung. The "stop" portion can take up to 10 minutes to complete. What can I be looking at to diagnose and/or debug this? We ought to be able to delete users, not just disable them, right? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From mkosek at redhat.com Wed Feb 5 15:30:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Feb 2014 16:30:06 +0100 Subject: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain In-Reply-To: References: <20140205073927.GF7586@redhat.com> Message-ID: <52F258FE.1040008@redhat.com> Good! Note that we plan to enhance SSSD to leverage the new Kerberos authlocal API to avoid having to update krb5.conf on each system. This is the upstream ticket: https://fedorahosted.org/sssd/ticket/1835 Martin On 02/05/2014 03:27 PM, Mark Gardner wrote: > Thanks, That was what I missed. > > > On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy wrote: > >> On Tue, 04 Feb 2014, Mark Gardner wrote: >> >>> I'm trying to configure our CentOS IPA Client for Single Sign On from our >>> trusted AD domain. >>> SSO works fine when I ssh to the IPA server, but not to the CentOS Client. >>> It prompts for password which it accepts, so it's getting the >>> authentication from the AD domain. >>> >>> Fedora 20 IPA Server >>> CentOS 6.5 IPA Client >>> Win 2012 AD Domain Server >>> >>> Setup as IPA as a subdomain of AD. >>> AD Domain: test.local >>> IPA Domain: hosted.test.local >>> >>> Anybody run into this? Suggestions? >>> >> Each client needs to be configured to accept AD users' SSO. >> >> Check that /etc/krb5.conf contains auth_to_local rules mapping principals >> from >> AD to their names as returned by SSSD. >> >> SSH daemon is picky about principal/name mapping. >> -- >> / Alexander Bokovoy >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mkosek at redhat.com Wed Feb 5 15:36:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Feb 2014 16:36:11 +0100 Subject: [Freeipa-users] Can't delete users In-Reply-To: <52F2579C.7070801@damascusgrp.com> References: <52F2579C.7070801@damascusgrp.com> Message-ID: <52F25A6B.6000304@redhat.com> On 02/05/2014 04:24 PM, Bret Wortman wrote: > We've discovered something odd in our current FreeIPA setup (F18, IPA > 3.1.5-1.fc18.x86_64). > > Whenever we go to delete a user, the whole IPA infrastructure will hang. The web > page becomes nonresponsive and the server doesn't respond to sudo or > authentication requests. DNS requests go unanswered. > > The only solution we've found thus far is to "ipactl stop && ipactl start". > Nothing ever shows up in any logfile we've looked at, presumably because > whatever ought to be logging an error is hung. The "stop" portion can take up to > 10 minutes to complete. > > What can I be looking at to diagnose and/or debug this? We ought to be able to > delete users, not just disable them, right? > > > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret This sounds to me as a hang of the 389 Directory Server. Adding Nathan and Rich to CC. They will certainly want to see a stack of the stuck 389 processes: http://directory.fedoraproject.org/wiki/FAQ#Debugging_Hangs Martin From bret.wortman at damascusgrp.com Wed Feb 5 15:38:35 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 05 Feb 2014 10:38:35 -0500 Subject: [Freeipa-users] Can't delete users In-Reply-To: <52F25A6B.6000304@redhat.com> References: <52F2579C.7070801@damascusgrp.com> <52F25A6B.6000304@redhat.com> Message-ID: <52F25AFB.3000009@damascusgrp.com> Fortunately, I can trigger it at will. ;-) I'll get the packages loaded & set up and see what I can find. On 02/05/2014 10:36 AM, Martin Kosek wrote: > On 02/05/2014 04:24 PM, Bret Wortman wrote: >> We've discovered something odd in our current FreeIPA setup (F18, IPA >> 3.1.5-1.fc18.x86_64). >> >> Whenever we go to delete a user, the whole IPA infrastructure will hang. The web >> page becomes nonresponsive and the server doesn't respond to sudo or >> authentication requests. DNS requests go unanswered. >> >> The only solution we've found thus far is to "ipactl stop && ipactl start". >> Nothing ever shows up in any logfile we've looked at, presumably because >> whatever ought to be logging an error is hung. The "stop" portion can take up to >> 10 minutes to complete. >> >> What can I be looking at to diagnose and/or debug this? We ought to be able to >> delete users, not just disable them, right? >> >> >> -- >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret > This sounds to me as a hang of the 389 Directory Server. Adding Nathan and Rich > to CC. > > They will certainly want to see a stack of the stuck 389 processes: > http://directory.fedoraproject.org/wiki/FAQ#Debugging_Hangs > > Martin > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From barrykfl at gmail.com Wed Feb 5 15:47:22 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 5 Feb 2014 23:47:22 +0800 Subject: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain In-Reply-To: <52F258FE.1040008@redhat.com> References: <20140205073927.GF7586@redhat.com> <52F258FE.1040008@redhat.com> Message-ID: Any one knows how to add new attribute or object class to the user accounts ...eg. added department and id creation date in those users info field. Can use 389 / redhat driectory console ? I tried to edit 99user.ldif seem not shown up new attribute. barry 2014-02-05 Martin Kosek : > Good! Note that we plan to enhance SSSD to leverage the new Kerberos > authlocal > API to avoid having to update krb5.conf on each system. This is the > upstream > ticket: > > https://fedorahosted.org/sssd/ticket/1835 > > Martin > > On 02/05/2014 03:27 PM, Mark Gardner wrote: > > Thanks, That was what I missed. > > > > > > On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy >wrote: > > > >> On Tue, 04 Feb 2014, Mark Gardner wrote: > >> > >>> I'm trying to configure our CentOS IPA Client for Single Sign On from > our > >>> trusted AD domain. > >>> SSO works fine when I ssh to the IPA server, but not to the CentOS > Client. > >>> It prompts for password which it accepts, so it's getting the > >>> authentication from the AD domain. > >>> > >>> Fedora 20 IPA Server > >>> CentOS 6.5 IPA Client > >>> Win 2012 AD Domain Server > >>> > >>> Setup as IPA as a subdomain of AD. > >>> AD Domain: test.local > >>> IPA Domain: hosted.test.local > >>> > >>> Anybody run into this? Suggestions? > >>> > >> Each client needs to be configured to accept AD users' SSO. > >> > >> Check that /etc/krb5.conf contains auth_to_local rules mapping > principals > >> from > >> AD to their names as returned by SSSD. > >> > >> SSH daemon is picky about principal/name mapping. > >> -- > >> / Alexander Bokovoy > >> > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 5 16:50:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Feb 2014 17:50:30 +0100 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) In-Reply-To: References: Message-ID: <52F26BD6.5040809@redhat.com> Steve Dainard wrote: > Following this guide: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html > > STEP 4: > ipa-server-install --setup-dns -p '' -a '' -r > MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux > --forwarder=10.0.0.2 --forwarder=10.0.0.5 > > Server host name [ipa1.miovision.linux]: > > Warning: skipping DNS resolution of host ipa1.miovision.linux > Unable to resolve IP address for host name > Please provide the IP address to be used for this host name: 10.0.6.3 > Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name [6.0.10.in-addr.arpa.]: > Using reverse zone 6.0.10.in-addr.arpa. > > The IPA Master Server will be configured with: > Hostname: ipa1.miovision.linux > IP address: 10.0.6.3 > Domain name: miovision.linux > Realm name: MIOVISION.LINUX > > BIND DNS server will be configured to serve IPA domain with: > Forwarders: 10.0.0.2, 10.0.0.5 > Reverse zone: 6.0.10.in-addr.arpa. > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > > ... > > Done configuring directory server (dirsrv). > Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds > [1/10]: adding sasl mappings to the directory > [2/10]: adding kerberos container to the directory > [3/10]: configuring KDC > [4/10]: initialize kerberos container > Failed to initialize the realm container > [5/10]: adding default ACIs > [6/10]: creating a keytab for the directory > Unexpected error - see /var/log/ipaserver-install.log for details: > CalledProcessError: Command 'kadmin.local -q addprinc -randkey > ldap/ipa1.miovision.linux at MIOVISION.LINUX -x > ipa-setup-override-restrictions' returned non-zero exit status 1 > > */var/log/ipaserver-install.log* > > add aci: > > (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux")(targetattr="userCertificate")(version > 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = > "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux";) > modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" > modify complete > > > 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( > ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) > > 2014-02-04T20:45:51Z DEBUG duration: 6 seconds > 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory > 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey > ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override-restrictions > 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal > root/admin at MIOVISION.LINUX with password. > > 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the > database while initializing kadmin.local interface > > 2014-02-04T20:45:51Z INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1024, in main > subject_base=options.subject) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 183, in create_instance > self.start_creation(runtime=30) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", > line 386, in __create_ds_keytab > installutils.kadmin_addprinc(ldap_principal) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 369, in kadmin_addprinc > kadmin("addprinc -randkey " + principal) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 366, in kadmin > "-x", "ipa-setup-override-restrictions"]) > > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line > 316, in run > raise CalledProcessError(p.returncode, args) > > 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, > exception: CalledProcessError: Command 'kadmin.local -q addprinc > -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x > ipa-setup-override-restrictions' returned non-zero exit status 1 > Steve sent me the logs out-of-band. I think the problem is an earlier failure after generating the master key: 2014-02-04T20:45:45Z DEBUG args=kdb5_util create -s -r MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:45Z DEBUG stdout=Loading random data Initializing database '/var/kerberos/krb5kdc/principal' for realm 'MIOVISION.LINUX', master key name 'K/M at MIOVISION.LINUX' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: 2014-02-04T20:45:45Z DEBUG stderr=kdb5_util: add.c:124: ldap_add_ext: Assertion `ld != ((void *)0)' failed. What version of krb5_server is installed? Does /var/log/messages indicate a segfault? Are there any failures in /var/log/dirsrv/slapd-MIOVISION-LINUX/errors? rob From sdainard at miovision.com Wed Feb 5 17:09:55 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 12:09:55 -0500 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) In-Reply-To: <52F26BD6.5040809@redhat.com> References: <52F26BD6.5040809@redhat.com> Message-ID: rpm -qa | grep krb5 pam_krb5-2.3.11-9.el6.x86_64 *krb5-server-1.10.3-10.el6_4.6.x86_64* krb5-libs-1.10.3-10.el6_4.6.x86_64 krb5-workstation-1.10.3-10.el6_4.6.x86_64 I don't see any segfaults in messages. /var/log/dirsrv/slapd-MIOVISION-LINUX/errors looks pretty clean: 389-Directory/1.2.11.15 B2013.337.1530 ipa1.miovision.linux:389 (/etc/dirsrv/slapd-MIOVISION-LINUX) [04/Feb/2014:15:39:54 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [04/Feb/2014:15:39:54 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 1497738, procpages: 51916 [04/Feb/2014:15:39:54 -0500] - Import allocates 2396380KB import cache. [04/Feb/2014:15:39:55 -0500] - import userRoot: Beginning import job... [04/Feb/2014:15:39:55 -0500] - import userRoot: Index buffering enabled with bucket size 100 [04/Feb/2014:15:39:56 -0500] - import userRoot: Processing file "/var/lib/dirsrv/boot.ldif" [04/Feb/2014:15:39:56 -0500] - import userRoot: Finished scanning file "/var/lib/dirsrv/boot.ldif" (1 entries) [04/Feb/2014:15:40:03 -0500] - import userRoot: Workers finished; cleaning up... [04/Feb/2014:15:40:04 -0500] - import userRoot: Workers cleaned up. [04/Feb/2014:15:40:05 -0500] - import userRoot: Cleaning up producer thread... [04/Feb/2014:15:40:05 -0500] - import userRoot: Indexing complete. Post-processing... [04/Feb/2014:15:40:06 -0500] - import userRoot: Generating numSubordinates complete. [04/Feb/2014:15:40:07 -0500] - Nothing to do to build ancestorid index [04/Feb/2014:15:40:08 -0500] - import userRoot: Flushing caches... [04/Feb/2014:15:40:08 -0500] - import userRoot: Closing files... [04/Feb/2014:15:40:10 -0500] - All database threads now stopped [04/Feb/2014:15:40:10 -0500] - import userRoot: Import complete. Processed 1 entries in 15 seconds. (0.07 entries/sec) [04/Feb/2014:15:40:18 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:40:19 -0500] - Db home directory is not set. Possibly nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the config file. [04/Feb/2014:15:40:19 -0500] - I'm resizing my cache now...cache was 2453893120 and is now 8000000 [04/Feb/2014:15:40:36 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:40:36 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:40:37 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:40:37 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:40:38 -0500] - All database threads now stopped [04/Feb/2014:15:40:38 -0500] - slapd stopped. [04/Feb/2014:15:40:40 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:40:41 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:40:43 -0500] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [04/Feb/2014:15:41:10 -0500] - Warning: Adding configuration attribute "nsslapd-security" [04/Feb/2014:15:41:13 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:41:14 -0500] - slapd shutting down - waiting for 30 threads to terminate [04/Feb/2014:15:41:14 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:41:15 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:41:17 -0500] - All database threads now stopped [04/Feb/2014:15:41:17 -0500] - slapd stopped. [04/Feb/2014:15:41:27 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:41:27 -0500] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [04/Feb/2014:15:41:28 -0500] attrcrypt - Key for cipher AES successfully generated and stored [04/Feb/2014:15:41:29 -0500] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [04/Feb/2014:15:41:29 -0500] attrcrypt - Key for cipher 3DES successfully generated and stored [04/Feb/2014:15:41:31 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:41:31 -0500] - Listening on All Interfaces port 636 for LDAPS requests [04/Feb/2014:15:41:32 -0500] - Listening on /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests [04/Feb/2014:15:42:06 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:31 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:44:33 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:44:44 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:44:47 -0500] - All database threads now stopped [04/Feb/2014:15:44:47 -0500] - slapd stopped. [04/Feb/2014:15:44:49 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:44:51 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:53 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:44:53 -0500] - Listening on All Interfaces port 636 for LDAPS requests [04/Feb/2014:15:44:53 -0500] - Listening on /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests [04/Feb/2014:15:44:53 -0500] - The change of nsslapd-maxdescriptors will not take effect until the server is restarted [05/Feb/2014:09:51:59 -0500] - slapd shutting down - signaling operation threads [05/Feb/2014:09:51:59 -0500] - slapd shutting down - waiting for 26 threads to terminate [05/Feb/2014:09:52:00 -0500] - slapd shutting down - closing down internal subsystems and plugins [05/Feb/2014:09:52:00 -0500] - Waiting for 4 database threads to stop [05/Feb/2014:09:52:00 -0500] - All database threads now stopped [05/Feb/2014:09:52:00 -0500] - slapd stopped. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 11:50 AM, Rob Crittenden wrote: > Steve Dainard wrote: > >> Following this guide: >> https://access.redhat.com/site/documentation/en-US/Red_ >> Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ >> trust-diff-dns-domains.html >> >> STEP 4: >> ipa-server-install --setup-dns -p '' -a '' -r >> MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux >> --forwarder=10.0.0.2 --forwarder=10.0.0.5 >> >> Server host name [ipa1.miovision.linux]: >> >> Warning: skipping DNS resolution of host ipa1.miovision.linux >> Unable to resolve IP address for host name >> Please provide the IP address to be used for this host name: 10.0.6.3 >> Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file >> Do you want to configure the reverse zone? [yes]: >> Please specify the reverse zone name [6.0.10.in-addr.arpa.]: >> Using reverse zone 6.0.10.in-addr.arpa. >> >> The IPA Master Server will be configured with: >> Hostname: ipa1.miovision.linux >> IP address: 10.0.6.3 >> Domain name: miovision.linux >> Realm name: MIOVISION.LINUX >> >> BIND DNS server will be configured to serve IPA domain with: >> Forwarders: 10.0.0.2, 10.0.0.5 >> Reverse zone: 6.0.10.in-addr.arpa. >> >> Continue to configure the system with these values? [no]: yes >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> >> ... >> >> Done configuring directory server (dirsrv). >> Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds >> [1/10]: adding sasl mappings to the directory >> [2/10]: adding kerberos container to the directory >> [3/10]: configuring KDC >> [4/10]: initialize kerberos container >> Failed to initialize the realm container >> [5/10]: adding default ACIs >> [6/10]: creating a keytab for the directory >> Unexpected error - see /var/log/ipaserver-install.log for details: >> CalledProcessError: Command 'kadmin.local -q addprinc -randkey >> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >> ipa-setup-override-restrictions' returned non-zero exit status 1 >> >> */var/log/ipaserver-install.log* >> >> >> add aci: >> >> (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc= >> miovision,dc=linux")(targetattr="userCertificate")(version >> 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = >> "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn= >> accounts,dc=miovision,dc=linux";) >> modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" >> modify complete >> >> >> 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( >> ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) >> >> 2014-02-04T20:45:51Z DEBUG duration: 6 seconds >> 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory >> 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey >> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override- >> restrictions >> 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal >> root/admin at MIOVISION.LINUX with password. >> >> 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the >> database while initializing kadmin.local interface >> >> 2014-02-04T20:45:51Z INFO File >> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >> line 614, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1024, in main >> subject_base=options.subject) >> >> File >> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >> line 183, in create_instance >> self.start_creation(runtime=30) >> >> File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", >> line 358, in start_creation >> method() >> >> File >> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >> line 386, in __create_ds_keytab >> installutils.kadmin_addprinc(ldap_principal) >> >> File >> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >> line 369, in kadmin_addprinc >> kadmin("addprinc -randkey " + principal) >> >> File >> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >> line 366, in kadmin >> "-x", "ipa-setup-override-restrictions"]) >> >> File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line >> 316, in run >> raise CalledProcessError(p.returncode, args) >> >> 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, >> exception: CalledProcessError: Command 'kadmin.local -q addprinc >> -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >> ipa-setup-override-restrictions' returned non-zero exit status 1 >> >> > Steve sent me the logs out-of-band. I think the problem is an earlier > failure after generating the master key: > > 2014-02-04T20:45:45Z DEBUG args=kdb5_util create -s -r MIOVISION.LINUX -x > ipa-setup-override-restrictions > 2014-02-04T20:45:45Z DEBUG stdout=Loading random data > Initializing database '/var/kerberos/krb5kdc/principal' for realm > 'MIOVISION.LINUX', > master key name 'K/M at MIOVISION.LINUX' > You will be prompted for the database Master Password. > It is important that you NOT FORGET this password. > Enter KDC database master key: > Re-enter KDC database master key to verify: > > > 2014-02-04T20:45:45Z DEBUG stderr=kdb5_util: add.c:124: ldap_add_ext: > Assertion `ld != ((void *)0)' failed. > > What version of krb5_server is installed? Does /var/log/messages indicate > a segfault? Are there any failures in /var/log/dirsrv/slapd- > MIOVISION-LINUX/errors? > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 5 17:31:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Feb 2014 12:31:54 -0500 Subject: [Freeipa-users] Adding attributes to the user object In-Reply-To: References: <20140205073927.GF7586@redhat.com> <52F258FE.1040008@redhat.com> Message-ID: <52F2758A.70005@redhat.com> On 02/05/2014 10:47 AM, barrykfl at gmail.com wrote: > Any one knows how to add new attribute or object class to the user > accounts ...eg. added department and id creation date in those users > info field. > > Can use 389 / redhat driectory console ? I tried to edit 99user.ldif > seem not shown up new attribute. I am changing the name of the thread since it is a different issue. You first need to decide what the schema is. Say you want a new custom attribute. Requirements *Please pay close attention to these requirements:* * All users and groups must still be initially created via the FreeIPA Web UI or CLI tools, but custom attributes can then be modified using the LDAP interface via ldapmodify or other programmatic methods. * All custom attributes must be referenced by a custom objectclass. This objectclass must be "AUXILIARY" and must not include any mandatory ("MUST") attributes, only optional ("MAY") attributes. Note that this is necessary to guarantee that object creation through the Web UI or CLI tools does not fail due to the lack of inclusion of a mandatory attribute. * Review all third-party schema to verify that objectclasses are AUXIALIARY and that all attributes are optional. * When creating custom schema, *NEVER* re-use an existing or well-known OID. Instead, apply for your own Enterprise Number from IANA . * Perform a backup - errors made to the schema could render your entire FreeIPA environment inoperable. At a minimum, perform a snapshot of your primary FreeIPA server. In event of a environment-wide failure, the environment can be rebuilt by redeploying the snapshotted master, and deploying new FreeIPA servers replicating from that master. Process 1. The schema must be in LDIF format. This is commonly provided for third party schemas. If creating your own custom schema, please review "8.1.4. Extending the Schema " of the Red Hat Directory Server 9 Administration Guide . *~/custom-schema.ldif* ------------------------------------------------------------------------ dn: cn=schema changetype: modify add: attributetypes attributetypes:( 1.3.6.1.4.1.42.2.27.5.1.12 NAME 'SolarisUserQualifier' DESC 'Per-user login attributes' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String' SINGLE-VALUE ) attributetypes:( 1.3.6.1.4.1.42.2.27.5.1.13 NAME 'SolarisAttrReserved1' DESC 'Reserved for future use' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String' SINGLE-VALUE ) attributetypes:( 1.3.6.1.4.1.42.2.27.5.1.14 NAME 'SolarisAttrReserved2' DESC 'Reserved for future use' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String' SINGLE-VALUE ) attributetypes:( 1.3.6.1.4.1.42.2.27.5.1.4 NAME 'SolarisAttrKeyValue' DESC 'Semi-colon separated key=value pairs of attributes' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5Match SYNTAX 'IA5String' SINGLE-VALUE ) - add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.2.3 NAME 'SolarisUserAttr' SUP top AUXILIARY DESC 'User attributes' MAY ( SolarisUserQualifier $ SolarisAttrReserved1 $ SolarisAttrReserved2 $ SolarisAttrKeyValue ) ) ------------------------------------------------------------------------ 2. Using "ldapmodify", authenticate as "cn=Directory Manager " to apply the custom schema: $> ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H ldap://localhost -f custom-schema.ldif 3. Log into FreeIPA. "IPA Server" tab, "Configuration" sub-tab, "User options" panel, "Default user objectclasses" list, and add "SolarisUserAttr". This will cause this objectclass to be applied to all newly created users. 1. Existing users need to be updated, using ldapmodify and LDIF: *update-existing-user.ldif* ------------------------------------------------------------------------ dn: uid=tux,cn=users,cn=accounts,dc=example,dc=com changetype: modify add: objectclass objectclass: SolarisUserAttr ------------------------------------------------------------------------ $> ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H ldap://localhost -f update-existing-user.ldif 2. Custom attributes can now be populated using ldapmodify and LDIF: *custom-data.ldif* ------------------------------------------------------------------------ dn: uid=tux,cn=users,cn=accounts,dc=example,dc=com changetype: modify add: SolarisAttrKeyValue SolarisAttrKeyValue: type=normal,roles=root,class;profiles=System Administrator ------------------------------------------------------------------------ $> ldapmodify -ZZ -x -D "cn=Directory Manager" -W -H ldap://localhost -f custom-data.ldif -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gidjefjh.png Type: image/png Size: 154748 bytes Desc: not available URL: From sdainard at miovision.com Wed Feb 5 17:33:28 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 12:33:28 -0500 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) In-Reply-To: References: <52F26BD6.5040809@redhat.com> Message-ID: I just restored the machine from a pre-install snapshot and tried again. For some reason we don't fail on the krb config but the installer reports db write errors when adding records: Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory [7/10]: creating a keytab for the machine [8/10]: adding the password extension to the directory [9/10]: starting the KDC [10/10]: configuring KDC to start on boot Done configuring Kerberos KDC (krb5kdc). Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on boot Done configuring kadmin. Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: configuring ipa_memcached to start on boot Done configuring ipa_memcached. Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete Sudo command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete Sudo command')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete HBAC rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete HBAC rule')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo command group,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add Sudo command group')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add Group Password Policy costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add Group Password Policy costemplate')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['nestedgroup', 'groupofnames', 'top']), ('member', [ipapython.dn.DN('cn=IT Security Specialist,cn=roles,cn=accounts,dc=miovision,dc=linux')]), ('cn', 'HBAC Administrator'), ('description', 'HBAC Administrator')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add Sudo rule')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete Group Password Policy costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete Group Password Policy costemplate')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', ['cn=Host Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux', 'cn=Host Enrollment,cn=privileges,cn=pbac,dc=miovision,dc=linux']), ('cn', 'Add krbPrincipalName to a host')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Manage Sudo command group membership,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Manage Sudo command group membership')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC service groups,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add HBAC service groups')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Remove SELinux User Maps,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', 'cn=SELinux User Map Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Remove SELinux User Maps')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Write IPA Configuration,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', 'cn=Write IPA Configuration,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Write IPA Configuration')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Manage HBAC rule membership,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Manage HBAC rule membership')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=SELinux User Map Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'nestedgroup']), ('cn', 'SELinux User Map Administrators'), ('description', 'SELinux User Map Administrators')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete Sudo rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete Sudo rule')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete HBAC services,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete HBAC services')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete Sudo command group,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete Sudo command group')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete Group Password Policy,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete Group Password Policy')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC services,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add HBAC services')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Delete HBAC service groups,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete HBAC service groups')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Modify Sudo command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Modify Sudo command')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add Sudo command')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Modify Group Password Policy costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Modify Group Password Policy costemplate')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add HBAC rule')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Modify Group membership,cn=privileges,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'nestedgroup']), ('member', 'cn=helpdesk,cn=roles,cn=accounts,dc=miovision,dc=linux'), ('cn', 'Modify Group membership'), ('description', 'Modify Group membership')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=IT Specialist,cn=roles,cn=accounts,dc=miovision,dc=linux: [('objectclass', ['groupofnames', 'nestedgroup', 'top']), ('cn', 'IT Specialist'), ('description', 'IT Specialist')] ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: Server is unwilling to perform: database is read-only ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server is unwilling to perform: database is read-only arguments: entry=cn=Add SELinux User Maps,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', 'cn=SELinux User Map Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add SELinux User Maps')] Restarting the directory server Restarting the KDC Configuring DNS (named) [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves Done configuring DNS (named). 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 ============================================================================== Setup complete Next steps: 1. You must make sure these network ports are open: TCP Ports: * 80, 443: HTTP/HTTPS * 389, 636: LDAP/LDAPS * 88, 464: kerberos * 53: bind UDP Ports: * 88, 464: kerberos * 53: bind * 123: ntp 2. You can now obtain a kerberos ticket using the command: 'kinit admin' This ticket will allow you to use the IPA tools (e.g., ipa user-add) and the web user interface. Be sure to back up the CA certificate stored in /root/cacert.p12 This file is required to create replicas. The password for this file is the Directory Manager password I'd attach the log file, but its 30MB in size... it looks like the DEBUG loglevel prints out all the inserts when building the db. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 12:09 PM, Steve Dainard wrote: > > > rpm -qa | grep krb5 > pam_krb5-2.3.11-9.el6.x86_64 > *krb5-server-1.10.3-10.el6_4.6.x86_64* > krb5-libs-1.10.3-10.el6_4.6.x86_64 > krb5-workstation-1.10.3-10.el6_4.6.x86_64 > > I don't see any segfaults in messages. > > /var/log/dirsrv/slapd-MIOVISION-LINUX/errors looks pretty clean: > > 389-Directory/1.2.11.15 B2013.337.1530 > ipa1.miovision.linux:389 (/etc/dirsrv/slapd-MIOVISION-LINUX) > > [04/Feb/2014:15:39:54 -0500] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to access the > database > [04/Feb/2014:15:39:54 -0500] - check_and_set_import_cache: pagesize: 4096, > pages: 1497738, procpages: 51916 > [04/Feb/2014:15:39:54 -0500] - Import allocates 2396380KB import cache. > [04/Feb/2014:15:39:55 -0500] - import userRoot: Beginning import job... > [04/Feb/2014:15:39:55 -0500] - import userRoot: Index buffering enabled > with bucket size 100 > [04/Feb/2014:15:39:56 -0500] - import userRoot: Processing file > "/var/lib/dirsrv/boot.ldif" > [04/Feb/2014:15:39:56 -0500] - import userRoot: Finished scanning file > "/var/lib/dirsrv/boot.ldif" (1 entries) > [04/Feb/2014:15:40:03 -0500] - import userRoot: Workers finished; cleaning > up... > [04/Feb/2014:15:40:04 -0500] - import userRoot: Workers cleaned up. > [04/Feb/2014:15:40:05 -0500] - import userRoot: Cleaning up producer > thread... > [04/Feb/2014:15:40:05 -0500] - import userRoot: Indexing complete. > Post-processing... > [04/Feb/2014:15:40:06 -0500] - import userRoot: Generating numSubordinates > complete. > [04/Feb/2014:15:40:07 -0500] - Nothing to do to build ancestorid index > [04/Feb/2014:15:40:08 -0500] - import userRoot: Flushing caches... > [04/Feb/2014:15:40:08 -0500] - import userRoot: Closing files... > [04/Feb/2014:15:40:10 -0500] - All database threads now stopped > [04/Feb/2014:15:40:10 -0500] - import userRoot: Import complete. > Processed 1 entries in 15 seconds. (0.07 entries/sec) > [04/Feb/2014:15:40:18 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [04/Feb/2014:15:40:19 -0500] - Db home directory is not set. Possibly > nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the > config file. > [04/Feb/2014:15:40:19 -0500] - I'm resizing my cache now...cache was > 2453893120 and is now 8000000 > [04/Feb/2014:15:40:36 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [04/Feb/2014:15:40:36 -0500] - slapd shutting down - signaling operation > threads > [04/Feb/2014:15:40:37 -0500] - slapd shutting down - closing down internal > subsystems and plugins > [04/Feb/2014:15:40:37 -0500] - Waiting for 4 database threads to stop > [04/Feb/2014:15:40:38 -0500] - All database threads now stopped > [04/Feb/2014:15:40:38 -0500] - slapd stopped. > [04/Feb/2014:15:40:40 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [04/Feb/2014:15:40:41 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [04/Feb/2014:15:40:43 -0500] - The change of nsslapd-ldapilisten will not > take effect until the server is restarted > [04/Feb/2014:15:41:10 -0500] - Warning: Adding configuration attribute > "nsslapd-security" > [04/Feb/2014:15:41:13 -0500] - slapd shutting down - signaling operation > threads > [04/Feb/2014:15:41:14 -0500] - slapd shutting down - waiting for 30 > threads to terminate > [04/Feb/2014:15:41:14 -0500] - slapd shutting down - closing down internal > subsystems and plugins > [04/Feb/2014:15:41:15 -0500] - Waiting for 4 database threads to stop > [04/Feb/2014:15:41:17 -0500] - All database threads now stopped > [04/Feb/2014:15:41:17 -0500] - slapd stopped. > [04/Feb/2014:15:41:27 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [04/Feb/2014:15:41:27 -0500] attrcrypt - No symmetric key found for cipher > AES in backend userRoot, attempting to create one... > [04/Feb/2014:15:41:28 -0500] attrcrypt - Key for cipher AES successfully > generated and stored > [04/Feb/2014:15:41:29 -0500] attrcrypt - No symmetric key found for cipher > 3DES in backend userRoot, attempting to create one... > [04/Feb/2014:15:41:29 -0500] attrcrypt - Key for cipher 3DES successfully > generated and stored > [04/Feb/2014:15:41:31 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [04/Feb/2014:15:41:31 -0500] - Listening on All Interfaces port 636 for > LDAPS requests > [04/Feb/2014:15:41:32 -0500] - Listening on > /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests > [04/Feb/2014:15:42:06 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which > should be added before the CoS Definition. > [04/Feb/2014:15:44:31 -0500] - slapd shutting down - signaling operation > threads > [04/Feb/2014:15:44:33 -0500] - slapd shutting down - closing down internal > subsystems and plugins > [04/Feb/2014:15:44:44 -0500] - Waiting for 4 database threads to stop > [04/Feb/2014:15:44:47 -0500] - All database threads now stopped > [04/Feb/2014:15:44:47 -0500] - slapd stopped. > [04/Feb/2014:15:44:49 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 > starting up > [04/Feb/2014:15:44:51 -0500] schema-compat-plugin - warning: no entries > set up under cn=computers, cn=compat,dc=miovision,dc=linux > [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries > set up under cn=ng, cn=compat,dc=miovision,dc=linux > [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries > set up under ou=sudoers,dc=miovision,dc=linux > [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which > should be added before the CoS Definition. > [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which > should be added before the CoS Definition. > [04/Feb/2014:15:44:53 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [04/Feb/2014:15:44:53 -0500] - Listening on All Interfaces port 636 for > LDAPS requests > [04/Feb/2014:15:44:53 -0500] - Listening on > /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests > [04/Feb/2014:15:44:53 -0500] - The change of nsslapd-maxdescriptors will > not take effect until the server is restarted > [05/Feb/2014:09:51:59 -0500] - slapd shutting down - signaling operation > threads > [05/Feb/2014:09:51:59 -0500] - slapd shutting down - waiting for 26 > threads to terminate > [05/Feb/2014:09:52:00 -0500] - slapd shutting down - closing down internal > subsystems and plugins > [05/Feb/2014:09:52:00 -0500] - Waiting for 4 database threads to stop > [05/Feb/2014:09:52:00 -0500] - All database threads now stopped > [05/Feb/2014:09:52:00 -0500] - slapd stopped. > > > Thanks, > > *Steve Dainard * > IT Infrastructure Manager > Miovision | *Rethink Traffic* > 519-513-2407 ex.250 > 877-646-8476 (toll-free) > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Wed, Feb 5, 2014 at 11:50 AM, Rob Crittenden wrote: > >> Steve Dainard wrote: >> >>> Following this guide: >>> https://access.redhat.com/site/documentation/en-US/Red_ >>> Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ >>> trust-diff-dns-domains.html >>> >>> STEP 4: >>> ipa-server-install --setup-dns -p '' -a '' -r >>> MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux >>> --forwarder=10.0.0.2 --forwarder=10.0.0.5 >>> >>> Server host name [ipa1.miovision.linux]: >>> >>> Warning: skipping DNS resolution of host ipa1.miovision.linux >>> Unable to resolve IP address for host name >>> Please provide the IP address to be used for this host name: 10.0.6.3 >>> Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file >>> Do you want to configure the reverse zone? [yes]: >>> Please specify the reverse zone name [6.0.10.in-addr.arpa.]: >>> Using reverse zone 6.0.10.in-addr.arpa. >>> >>> The IPA Master Server will be configured with: >>> Hostname: ipa1.miovision.linux >>> IP address: 10.0.6.3 >>> Domain name: miovision.linux >>> Realm name: MIOVISION.LINUX >>> >>> BIND DNS server will be configured to serve IPA domain with: >>> Forwarders: 10.0.0.2, 10.0.0.5 >>> Reverse zone: 6.0.10.in-addr.arpa. >>> >>> Continue to configure the system with these values? [no]: yes >>> >>> The following operations may take some minutes to complete. >>> Please wait until the prompt is returned. >>> >>> Configuring NTP daemon (ntpd) >>> [1/4]: stopping ntpd >>> >>> ... >>> >>> Done configuring directory server (dirsrv). >>> Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds >>> [1/10]: adding sasl mappings to the directory >>> [2/10]: adding kerberos container to the directory >>> [3/10]: configuring KDC >>> [4/10]: initialize kerberos container >>> Failed to initialize the realm container >>> [5/10]: adding default ACIs >>> [6/10]: creating a keytab for the directory >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> CalledProcessError: Command 'kadmin.local -q addprinc -randkey >>> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >>> ipa-setup-override-restrictions' returned non-zero exit status 1 >>> >>> */var/log/ipaserver-install.log* >>> >>> >>> add aci: >>> >>> (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc= >>> miovision,dc=linux")(targetattr="userCertificate")(version >>> 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = >>> "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn= >>> accounts,dc=miovision,dc=linux";) >>> modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" >>> modify complete >>> >>> >>> 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( >>> ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) >>> >>> 2014-02-04T20:45:51Z DEBUG duration: 6 seconds >>> 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory >>> 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey >>> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override- >>> restrictions >>> 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal >>> root/admin at MIOVISION.LINUX with password. >>> >>> 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the >>> database while initializing kadmin.local interface >>> >>> 2014-02-04T20:45:51Z INFO File >>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>> line 614, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-server-install", line 1024, in main >>> subject_base=options.subject) >>> >>> File >>> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >>> line 183, in create_instance >>> self.start_creation(runtime=30) >>> >>> File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", >>> line 358, in start_creation >>> method() >>> >>> File >>> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >>> line 386, in __create_ds_keytab >>> installutils.kadmin_addprinc(ldap_principal) >>> >>> File >>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>> line 369, in kadmin_addprinc >>> kadmin("addprinc -randkey " + principal) >>> >>> File >>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>> line 366, in kadmin >>> "-x", "ipa-setup-override-restrictions"]) >>> >>> File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line >>> 316, in run >>> raise CalledProcessError(p.returncode, args) >>> >>> 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, >>> exception: CalledProcessError: Command 'kadmin.local -q addprinc >>> -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >>> ipa-setup-override-restrictions' returned non-zero exit status 1 >>> >>> >> Steve sent me the logs out-of-band. I think the problem is an earlier >> failure after generating the master key: >> >> 2014-02-04T20:45:45Z DEBUG args=kdb5_util create -s -r MIOVISION.LINUX -x >> ipa-setup-override-restrictions >> 2014-02-04T20:45:45Z DEBUG stdout=Loading random data >> Initializing database '/var/kerberos/krb5kdc/principal' for realm >> 'MIOVISION.LINUX', >> master key name 'K/M at MIOVISION.LINUX' >> You will be prompted for the database Master Password. >> It is important that you NOT FORGET this password. >> Enter KDC database master key: >> Re-enter KDC database master key to verify: >> >> >> 2014-02-04T20:45:45Z DEBUG stderr=kdb5_util: add.c:124: ldap_add_ext: >> Assertion `ld != ((void *)0)' failed. >> >> What version of krb5_server is installed? Does /var/log/messages indicate >> a segfault? Are there any failures in /var/log/dirsrv/slapd- >> MIOVISION-LINUX/errors? >> >> rob >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 5 17:34:37 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Feb 2014 12:34:37 -0500 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: References: <52D9BFD7.30406@redhat.com> Message-ID: <52F2762D.2090701@redhat.com> On 02/04/2014 03:28 PM, Steve Dainard wrote: > > > >> has anyone worked it out. Secondly cifs-utils has dependency on >> samba3 packages and ipa-ad-trust needs samba4 but samba3 and >> samba4 don't like each other , so this is the story of my >> experience with ipa. Any suggestions ? > > Why do you need cifs-utils on the same server? > cifs-utils to make a system a client to MSFT file server, AFAIU > you cant make IPA server to be a cifs client. > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html > > Step 3 mentions that cifs-utils is required, but: > > yum install cifs-utils > Loaded plugins: product-id, security, subscription-manager > This system is receiving updates from Red Hat Subscription Management. > rhel-6-server-cf-tools-1-rpms | 2.8 kB > 00:00 > rhel-6-server-rhev-agent-rpms | 3.1 kB > 00:00 > rhel-6-server-rpms | 3.7 kB > 00:00 > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed > --> Processing Dependency: libwbclient.so.0()(64bit) for package: > cifs-utils-4.8.1-19.el6.x86_64 > --> Running transaction check > ---> Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be > installed > --> Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for > package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 > --> Running transaction check > ---> Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed > --> Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: > samba-winbind-3.6.9-167.el6_5.x86_64 > --> Running transaction check > ---> Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed > --> Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 > conflicts samba-common < 3.9.9 > --> Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 > conflicts samba-winbind < 3.9.9 > --> Processing Conflict: > samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts > samba-winbind-clients < 3.9.9 > --> Finished Dependency Resolution > Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 > Error: samba4-winbind-clients conflicts with > samba-winbind-clients-3.6.9-167.el6_5.x86_64 > Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > Is this no longer a requirement? Can this documentation be updated? > > Steve > > Can you please file a BZ? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maleko42 at gmail.com Wed Feb 5 18:44:13 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Wed, 5 Feb 2014 13:44:13 -0500 Subject: [Freeipa-users] More SSO Strangeness Message-ID: Okay, Spent some time on this one... Some users can login SSO no problem, others have to put in their password. Strange as it seems, if the length of the username was greater than 4, the SSO worked. So markg at test.local works, but mark at test.local doesn't. My guess is something to do with the NetBios name length? Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Wed Feb 5 19:24:11 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 14:24:11 -0500 Subject: [Freeipa-users] ipa-server-install fails (RHEL 6.5) In-Reply-To: References: <52F26BD6.5040809@redhat.com> Message-ID: And another re-install after snapshot restore gives me no errors. Perhaps there are some race conditions during initial install? *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 12:33 PM, Steve Dainard wrote: > I just restored the machine from a pre-install snapshot and tried again. > For some reason we don't fail on the krb config but the installer reports > db write errors when adding records: > > Done configuring directory server (dirsrv). > Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds > [1/10]: adding sasl mappings to the directory > [2/10]: adding kerberos container to the directory > [3/10]: configuring KDC > [4/10]: initialize kerberos container > [5/10]: adding default ACIs > [6/10]: creating a keytab for the directory > [7/10]: creating a keytab for the machine > [8/10]: adding the password extension to the directory > [9/10]: starting the KDC > [10/10]: configuring KDC to start on boot > Done configuring Kerberos KDC (krb5kdc). > Configuring kadmin > [1/2]: starting kadmin > [2/2]: configuring kadmin to start on boot > Done configuring kadmin. > Configuring ipa_memcached > [1/2]: starting ipa_memcached > [2/2]: configuring ipa_memcached to start on boot > Done configuring ipa_memcached. > Configuring the web interface (httpd): Estimated time 1 minute > [1/13]: setting mod_nss port to 443 > [2/13]: setting mod_nss password file > [3/13]: enabling mod_nss renegotiate > [4/13]: adding URL rewriting rules > [5/13]: configuring httpd > [6/13]: setting up ssl > [7/13]: setting up browser autoconfig > [8/13]: publish CA cert > [9/13]: creating a keytab for httpd > [10/13]: clean up any existing httpd ccache > [11/13]: configuring SELinux for httpd > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > Sudo command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete > Sudo command')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > HBAC rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete > HBAC rule')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo > command group,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Add Sudo command group')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add > Group Password Policy > costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > Group Password Policy costemplate')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=HBAC > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['nestedgroup', 'groupofnames', 'top']), ('member', [ipapython.dn.DN('cn=IT > Security Specialist,cn=roles,cn=accounts,dc=miovision,dc=linux')]), ('cn', > 'HBAC Administrator'), ('description', 'HBAC Administrator')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo > rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > Sudo rule')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > Group Password Policy > costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete > Group Password Policy costemplate')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add > krbPrincipalName to a host,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', > ['cn=Host Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux', > 'cn=Host Enrollment,cn=privileges,cn=pbac,dc=miovision,dc=linux']), ('cn', > 'Add krbPrincipalName to a host')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Manage > Sudo command group membership,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Manage Sudo command group membership')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC > service groups,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Add HBAC service groups')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Remove > SELinux User Maps,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', > 'cn=SELinux User Map > Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', > 'Remove SELinux User Maps')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Write > IPA Configuration,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', > 'cn=Write IPA Configuration,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Write IPA Configuration')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Manage > HBAC rule membership,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Manage HBAC rule membership')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=SELinux > User Map Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'nestedgroup']), ('cn', 'SELinux > User Map Administrators'), ('description', 'SELinux User Map > Administrators')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > Sudo rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete > Sudo rule')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > HBAC services,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Delete HBAC services')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > Sudo command group,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=Sudo Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Delete Sudo command group')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > Group Password Policy,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=Password Policy > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Delete > Group Password Policy')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC > services,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > HBAC services')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Delete > HBAC service groups,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['groupofnames', 'ipapermission', 'top']), ('member', > 'cn=HBAC Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), > ('cn', 'Delete HBAC service groups')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Modify > Sudo command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Modify > Sudo command')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add Sudo > command,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Sudo > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > Sudo command')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Modify > Group Password Policy > costemplate,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=Password Policy > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Modify > Group Password Policy costemplate')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add HBAC > rule,cn=permissions,cn=pbac,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'ipapermission', 'top']), ('member', 'cn=HBAC > Administrator,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > HBAC rule')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Modify > Group membership,cn=privileges,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'nestedgroup']), ('member', > 'cn=helpdesk,cn=roles,cn=accounts,dc=miovision,dc=linux'), ('cn', 'Modify > Group membership'), ('description', 'Modify Group membership')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=IT > Specialist,cn=roles,cn=accounts,dc=miovision,dc=linux: [('objectclass', > ['groupofnames', 'nestedgroup', 'top']), ('cn', 'IT Specialist'), > ('description', 'IT Specialist')] > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Update failed: > Server is unwilling to perform: database is read-only > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure Server > is unwilling to perform: database is read-only arguments: entry=cn=Add > SELinux User Maps,cn=permissions,cn=pbac,dc=miovision,dc=linux: > [('objectclass', ['top', 'groupofnames', 'ipapermission']), ('member', > 'cn=SELinux User Map > Administrators,cn=privileges,cn=pbac,dc=miovision,dc=linux'), ('cn', 'Add > SELinux User Maps')] > Restarting the directory server > Restarting the KDC > Configuring DNS (named) > [1/9]: adding DNS container > [2/9]: setting up our zone > [3/9]: setting up reverse zone > [4/9]: setting up our own record > [5/9]: setting up kerberos principal > [6/9]: setting up named.conf > [7/9]: restarting named > [8/9]: configuring named to start on boot > [9/9]: changing resolv.conf to point to ourselves > Done configuring DNS (named). > > 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 > > ============================================================================== > Setup complete > > Next steps: > 1. You must make sure these network ports are open: > TCP Ports: > * 80, 443: HTTP/HTTPS > * 389, 636: LDAP/LDAPS > * 88, 464: kerberos > * 53: bind > UDP Ports: > * 88, 464: kerberos > * 53: bind > * 123: ntp > > 2. You can now obtain a kerberos ticket using the command: 'kinit admin' > This ticket will allow you to use the IPA tools (e.g., ipa user-add) > and the web user interface. > > Be sure to back up the CA certificate stored in /root/cacert.p12 > This file is required to create replicas. The password for this > file is the Directory Manager password > > > > I'd attach the log file, but its 30MB in size... it looks like the DEBUG > loglevel prints out all the inserts when building the db. > > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | *Rethink Traffic* > 519-513-2407 ex.250 > 877-646-8476 (toll-free) > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Wed, Feb 5, 2014 at 12:09 PM, Steve Dainard wrote: > >> >> >> rpm -qa | grep krb5 >> pam_krb5-2.3.11-9.el6.x86_64 >> *krb5-server-1.10.3-10.el6_4.6.x86_64* >> krb5-libs-1.10.3-10.el6_4.6.x86_64 >> krb5-workstation-1.10.3-10.el6_4.6.x86_64 >> >> I don't see any segfaults in messages. >> >> /var/log/dirsrv/slapd-MIOVISION-LINUX/errors looks pretty clean: >> >> 389-Directory/1.2.11.15 B2013.337.1530 >> ipa1.miovision.linux:389 (/etc/dirsrv/slapd-MIOVISION-LINUX) >> >> [04/Feb/2014:15:39:54 -0500] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to access the >> database >> [04/Feb/2014:15:39:54 -0500] - check_and_set_import_cache: pagesize: >> 4096, pages: 1497738, procpages: 51916 >> [04/Feb/2014:15:39:54 -0500] - Import allocates 2396380KB import cache. >> [04/Feb/2014:15:39:55 -0500] - import userRoot: Beginning import job... >> [04/Feb/2014:15:39:55 -0500] - import userRoot: Index buffering enabled >> with bucket size 100 >> [04/Feb/2014:15:39:56 -0500] - import userRoot: Processing file >> "/var/lib/dirsrv/boot.ldif" >> [04/Feb/2014:15:39:56 -0500] - import userRoot: Finished scanning file >> "/var/lib/dirsrv/boot.ldif" (1 entries) >> [04/Feb/2014:15:40:03 -0500] - import userRoot: Workers finished; >> cleaning up... >> [04/Feb/2014:15:40:04 -0500] - import userRoot: Workers cleaned up. >> [04/Feb/2014:15:40:05 -0500] - import userRoot: Cleaning up producer >> thread... >> [04/Feb/2014:15:40:05 -0500] - import userRoot: Indexing complete. >> Post-processing... >> [04/Feb/2014:15:40:06 -0500] - import userRoot: Generating >> numSubordinates complete. >> [04/Feb/2014:15:40:07 -0500] - Nothing to do to build ancestorid index >> [04/Feb/2014:15:40:08 -0500] - import userRoot: Flushing caches... >> [04/Feb/2014:15:40:08 -0500] - import userRoot: Closing files... >> [04/Feb/2014:15:40:10 -0500] - All database threads now stopped >> [04/Feb/2014:15:40:10 -0500] - import userRoot: Import complete. >> Processed 1 entries in 15 seconds. (0.07 entries/sec) >> [04/Feb/2014:15:40:18 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [04/Feb/2014:15:40:19 -0500] - Db home directory is not set. Possibly >> nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the >> config file. >> [04/Feb/2014:15:40:19 -0500] - I'm resizing my cache now...cache was >> 2453893120 and is now 8000000 >> [04/Feb/2014:15:40:36 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [04/Feb/2014:15:40:36 -0500] - slapd shutting down - signaling operation >> threads >> [04/Feb/2014:15:40:37 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [04/Feb/2014:15:40:37 -0500] - Waiting for 4 database threads to stop >> [04/Feb/2014:15:40:38 -0500] - All database threads now stopped >> [04/Feb/2014:15:40:38 -0500] - slapd stopped. >> [04/Feb/2014:15:40:40 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [04/Feb/2014:15:40:41 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [04/Feb/2014:15:40:43 -0500] - The change of nsslapd-ldapilisten will not >> take effect until the server is restarted >> [04/Feb/2014:15:41:10 -0500] - Warning: Adding configuration attribute >> "nsslapd-security" >> [04/Feb/2014:15:41:13 -0500] - slapd shutting down - signaling operation >> threads >> [04/Feb/2014:15:41:14 -0500] - slapd shutting down - waiting for 30 >> threads to terminate >> [04/Feb/2014:15:41:14 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [04/Feb/2014:15:41:15 -0500] - Waiting for 4 database threads to stop >> [04/Feb/2014:15:41:17 -0500] - All database threads now stopped >> [04/Feb/2014:15:41:17 -0500] - slapd stopped. >> [04/Feb/2014:15:41:27 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [04/Feb/2014:15:41:27 -0500] attrcrypt - No symmetric key found for >> cipher AES in backend userRoot, attempting to create one... >> [04/Feb/2014:15:41:28 -0500] attrcrypt - Key for cipher AES successfully >> generated and stored >> [04/Feb/2014:15:41:29 -0500] attrcrypt - No symmetric key found for >> cipher 3DES in backend userRoot, attempting to create one... >> [04/Feb/2014:15:41:29 -0500] attrcrypt - Key for cipher 3DES successfully >> generated and stored >> [04/Feb/2014:15:41:31 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [04/Feb/2014:15:41:31 -0500] - Listening on All Interfaces port 636 for >> LDAPS requests >> [04/Feb/2014:15:41:32 -0500] - Listening on >> /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests >> [04/Feb/2014:15:42:06 -0500] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which >> should be added before the CoS Definition. >> [04/Feb/2014:15:44:31 -0500] - slapd shutting down - signaling operation >> threads >> [04/Feb/2014:15:44:33 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [04/Feb/2014:15:44:44 -0500] - Waiting for 4 database threads to stop >> [04/Feb/2014:15:44:47 -0500] - All database threads now stopped >> [04/Feb/2014:15:44:47 -0500] - slapd stopped. >> [04/Feb/2014:15:44:49 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 >> starting up >> [04/Feb/2014:15:44:51 -0500] schema-compat-plugin - warning: no entries >> set up under cn=computers, cn=compat,dc=miovision,dc=linux >> [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries >> set up under cn=ng, cn=compat,dc=miovision,dc=linux >> [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries >> set up under ou=sudoers,dc=miovision,dc=linux >> [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which >> should be added before the CoS Definition. >> [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which >> should be added before the CoS Definition. >> [04/Feb/2014:15:44:53 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [04/Feb/2014:15:44:53 -0500] - Listening on All Interfaces port 636 for >> LDAPS requests >> [04/Feb/2014:15:44:53 -0500] - Listening on >> /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests >> [04/Feb/2014:15:44:53 -0500] - The change of nsslapd-maxdescriptors will >> not take effect until the server is restarted >> [05/Feb/2014:09:51:59 -0500] - slapd shutting down - signaling operation >> threads >> [05/Feb/2014:09:51:59 -0500] - slapd shutting down - waiting for 26 >> threads to terminate >> [05/Feb/2014:09:52:00 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [05/Feb/2014:09:52:00 -0500] - Waiting for 4 database threads to stop >> [05/Feb/2014:09:52:00 -0500] - All database threads now stopped >> [05/Feb/2014:09:52:00 -0500] - slapd stopped. >> >> >> Thanks, >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | *Rethink Traffic* >> 519-513-2407 ex.250 >> 877-646-8476 (toll-free) >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------ >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, >> ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or confidential. >> If you are not the intended recipient, please delete the e-mail and any >> attachments and notify us immediately. >> >> >> On Wed, Feb 5, 2014 at 11:50 AM, Rob Crittenden wrote: >> >>> Steve Dainard wrote: >>> >>>> Following this guide: >>>> https://access.redhat.com/site/documentation/en-US/Red_ >>>> Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ >>>> trust-diff-dns-domains.html >>>> >>>> STEP 4: >>>> ipa-server-install --setup-dns -p '' -a '' -r >>>> MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux >>>> --forwarder=10.0.0.2 --forwarder=10.0.0.5 >>>> >>>> Server host name [ipa1.miovision.linux]: >>>> >>>> Warning: skipping DNS resolution of host ipa1.miovision.linux >>>> Unable to resolve IP address for host name >>>> Please provide the IP address to be used for this host name: 10.0.6.3 >>>> Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file >>>> Do you want to configure the reverse zone? [yes]: >>>> Please specify the reverse zone name [6.0.10.in-addr.arpa.]: >>>> Using reverse zone 6.0.10.in-addr.arpa. >>>> >>>> The IPA Master Server will be configured with: >>>> Hostname: ipa1.miovision.linux >>>> IP address: 10.0.6.3 >>>> Domain name: miovision.linux >>>> Realm name: MIOVISION.LINUX >>>> >>>> BIND DNS server will be configured to serve IPA domain with: >>>> Forwarders: 10.0.0.2, 10.0.0.5 >>>> Reverse zone: 6.0.10.in-addr.arpa. >>>> >>>> Continue to configure the system with these values? [no]: yes >>>> >>>> The following operations may take some minutes to complete. >>>> Please wait until the prompt is returned. >>>> >>>> Configuring NTP daemon (ntpd) >>>> [1/4]: stopping ntpd >>>> >>>> ... >>>> >>>> Done configuring directory server (dirsrv). >>>> Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds >>>> [1/10]: adding sasl mappings to the directory >>>> [2/10]: adding kerberos container to the directory >>>> [3/10]: configuring KDC >>>> [4/10]: initialize kerberos container >>>> Failed to initialize the realm container >>>> [5/10]: adding default ACIs >>>> [6/10]: creating a keytab for the directory >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> CalledProcessError: Command 'kadmin.local -q addprinc -randkey >>>> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >>>> ipa-setup-override-restrictions' returned non-zero exit status 1 >>>> >>>> */var/log/ipaserver-install.log* >>>> >>>> >>>> add aci: >>>> >>>> (target="ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc= >>>> miovision,dc=linux")(targetattr="userCertificate")(version >>>> 3.0; acl "Modify CA Certificates for renewals"; allow(write) userdn = >>>> "ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn= >>>> accounts,dc=miovision,dc=linux";) >>>> modifying entry "cn=ipa,cn=etc,dc=miovision,dc=linux" >>>> modify complete >>>> >>>> >>>> 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( >>>> ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) >>>> >>>> 2014-02-04T20:45:51Z DEBUG duration: 6 seconds >>>> 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory >>>> 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey >>>> ldap/ipa1.miovision.linux at MIOVISION.LINUX -x ipa-setup-override- >>>> restrictions >>>> 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal >>>> root/admin at MIOVISION.LINUX with password. >>>> >>>> 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the >>>> database while initializing kadmin.local interface >>>> >>>> 2014-02-04T20:45:51Z INFO File >>>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>>> line 614, in run_script >>>> return_value = main_function() >>>> >>>> File "/usr/sbin/ipa-server-install", line 1024, in main >>>> subject_base=options.subject) >>>> >>>> File >>>> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >>>> line 183, in create_instance >>>> self.start_creation(runtime=30) >>>> >>>> File "/usr/lib/python2.6/site-packages/ipaserver/install/ >>>> service.py", >>>> line 358, in start_creation >>>> method() >>>> >>>> File >>>> "/usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py", >>>> line 386, in __create_ds_keytab >>>> installutils.kadmin_addprinc(ldap_principal) >>>> >>>> File >>>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>>> line 369, in kadmin_addprinc >>>> kadmin("addprinc -randkey " + principal) >>>> >>>> File >>>> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >>>> line 366, in kadmin >>>> "-x", "ipa-setup-override-restrictions"]) >>>> >>>> File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line >>>> 316, in run >>>> raise CalledProcessError(p.returncode, args) >>>> >>>> 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, >>>> exception: CalledProcessError: Command 'kadmin.local -q addprinc >>>> -randkey ldap/ipa1.miovision.linux at MIOVISION.LINUX -x >>>> ipa-setup-override-restrictions' returned non-zero exit status 1 >>>> >>>> >>> Steve sent me the logs out-of-band. I think the problem is an earlier >>> failure after generating the master key: >>> >>> 2014-02-04T20:45:45Z DEBUG args=kdb5_util create -s -r MIOVISION.LINUX >>> -x ipa-setup-override-restrictions >>> 2014-02-04T20:45:45Z DEBUG stdout=Loading random data >>> Initializing database '/var/kerberos/krb5kdc/principal' for realm >>> 'MIOVISION.LINUX', >>> master key name 'K/M at MIOVISION.LINUX' >>> You will be prompted for the database Master Password. >>> It is important that you NOT FORGET this password. >>> Enter KDC database master key: >>> Re-enter KDC database master key to verify: >>> >>> >>> 2014-02-04T20:45:45Z DEBUG stderr=kdb5_util: add.c:124: ldap_add_ext: >>> Assertion `ld != ((void *)0)' failed. >>> >>> What version of krb5_server is installed? Does /var/log/messages >>> indicate a segfault? Are there any failures in /var/log/dirsrv/slapd- >>> MIOVISION-LINUX/errors? >>> >>> rob >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Wed Feb 5 19:38:08 2014 From: mail at willsheldon.com (Will Sheldon) Date: Wed, 5 Feb 2014 11:38:08 -0800 Subject: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3) In-Reply-To: <52F205D0.3040300@redhat.com> References: <52F205D0.3040300@redhat.com> Message-ID: On 2/5/2014, 1:35 AM, Rob Crittenden wrote: > Will Sheldon wrote: > > > > Hello IPA users :) > > > > We have implemented IPA using the packaged version in centos 6.5 (which > > is 3.0.0-37.el6), but have been playing with the more recent version in > > Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the > > shiny new features, so are thinking about migrating. > > > > Has anyone done this? Is there an easy way to migrate/upgrade? > > What would happen if I tried to setup a FC19 replica, would it get angry > > and break? > > > > We only have users in production so far, (no production clients or > > issued certs) so maybe the user migration script mentioned in previous > > posts would be the best bet? > > > > Any pointers would be hugely appreciated.. > > This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. > > We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. > > rob > Yay! That?s easier than I thought it would be, thanks Rob. Would this work as a solution? 1) Leave current centos server (ipa.domain.com (http://ipa.domain.com)) in production 2) Configure new FC19 ipa server as a replica (newipa.domain.com (http://newipa.domain.com)) using the server install script 3) Check that newipa.domain.com (http://newipa.domain.com) is functioning as expected. 4) Remove centos server from production (not checked, but I assume there is a documented process for this) 5) Install new FC19 replica using same IP and DNS name as the old centos server (ipa.domain.com). -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Feb 5 19:38:52 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 05 Feb 2014 14:38:52 -0500 Subject: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3) In-Reply-To: <52F205D0.3040300@redhat.com> References: <52F205D0.3040300@redhat.com> Message-ID: <52F2934C.5040903@damascusgrp.com> Rob, To add the second master-with-CA, is it as simple as doing this on one of the replicas? # ipa-ca-install /path/to/replica-info-hostname.foo.net.gpg Bret On 02/05/2014 04:35 AM, Rob Crittenden wrote: > Will Sheldon wrote: >> >> Hello IPA users :) >> >> We have implemented IPA using the packaged version in centos 6.5 (which >> is 3.0.0-37.el6), but have been playing with the more recent version in >> Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the >> shiny new features, so are thinking about migrating. >> >> Has anyone done this? Is there an easy way to migrate/upgrade? >> What would happen if I tried to setup a FC19 replica, would it get angry >> and break? >> >> We only have users in production so far, (no production clients or >> issued certs) so maybe the user migration script mentioned in previous >> posts would be the best bet? >> >> Any pointers would be hugely appreciated.. > > This is exactly the way to migrate between versions. You'll want to > set up a CA on the F19 server for sure, and DNS if you're using that. > The idea is that you set up the new master, spend some time (days, > weeks not months) verifying that things are working ok, then remove > the old server and things should continue to just work. We also > recommend having at least two masters with CAs for redundancy and > avoiding a single point of failure. > > We have discovered a bug in the way clients are enrolled though. We > store the name of the master you enroll against. Normally this isn't a > big deal, especially if you use SRV records. The problem is if that > some tools use the master from this file to connect to and not SRV > records, so you may want to run around to your clients and change this > in /etc/ipa/default.conf once the migration is complete. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From mkosek at redhat.com Wed Feb 5 19:48:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Feb 2014 20:48:58 +0100 Subject: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3) In-Reply-To: <52F2934C.5040903@damascusgrp.com> References: <52F205D0.3040300@redhat.com> <52F2934C.5040903@damascusgrp.com> Message-ID: <52F295AA.2080805@redhat.com> The installation part is indeed that simple, but you will also want to additionally turn the new CA to be the "master CA" so that it properly generates the CRL and renews the CA subsystem certificates when the old "master CA" is decommissioned. See [1] and [2] for more information. Martin [1] http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS [2] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Reconfigure_a_CA_as_the_new_master On 02/05/2014 08:38 PM, Bret Wortman wrote: > Rob, > > To add the second master-with-CA, is it as simple as doing this on one of the > replicas? > > # ipa-ca-install /path/to/replica-info-hostname.foo.net.gpg > > > > Bret > > On 02/05/2014 04:35 AM, Rob Crittenden wrote: >> Will Sheldon wrote: >>> >>> Hello IPA users :) >>> >>> We have implemented IPA using the packaged version in centos 6.5 (which >>> is 3.0.0-37.el6), but have been playing with the more recent version in >>> Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the >>> shiny new features, so are thinking about migrating. >>> >>> Has anyone done this? Is there an easy way to migrate/upgrade? >>> What would happen if I tried to setup a FC19 replica, would it get angry >>> and break? >>> >>> We only have users in production so far, (no production clients or >>> issued certs) so maybe the user migration script mentioned in previous >>> posts would be the best bet? >>> >>> Any pointers would be hugely appreciated.. >> >> This is exactly the way to migrate between versions. You'll want to set up a >> CA on the F19 server for sure, and DNS if you're using that. The idea is that >> you set up the new master, spend some time (days, weeks not months) verifying >> that things are working ok, then remove the old server and things should >> continue to just work. We also recommend having at least two masters with CAs >> for redundancy and avoiding a single point of failure. >> >> We have discovered a bug in the way clients are enrolled though. We store the >> name of the master you enroll against. Normally this isn't a big deal, >> especially if you use SRV records. The problem is if that some tools use the >> master from this file to connect to and not SRV records, so you may want to >> run around to your clients and change this in /etc/ipa/default.conf once the >> migration is complete. >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sdainard at miovision.com Wed Feb 5 20:22:42 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 15:22:42 -0500 Subject: [Freeipa-users] Cross domain trust Message-ID: After the initial setup of a trust I'm attempting to get kerberos tickets against the AD domain. Step 12 in this document: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: Then, request service tickets for services within the Active Directory domain. [root at ipaserver ]# kvno cifs/adserver.adexample.com at AD.DOMAIN If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/AD.DOMAIN at IPA.DOMAIN. I get an error back: # kvno cifs/dc1.miovision.corp at MIOVISION.CORP kvno: Server not found in Kerberos database while getting credentials for cifs/dc1.miovision.corp at MIOVISION.CORP But I do have a krbtgt ticket/AD domain: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: sdainard-root at MIOLINUX.CORP Valid starting Expires Service principal 02/05/14 14:21:06 02/06/14 14:21:06 krbtgt/MIOLINUX.CORP at MIOLINUX.CORP 02/05/14 14:21:17 02/06/14 14:21:06 host/ipa1.miolinux.corp at MIOLINUX.CORP 02/05/14 14:21:20 02/06/14 14:21:06 krbtgt/MIOVISION.CORP at MIOLINUX.CORP Also, is it normal to not find the Linux realm listed in the domain trust list on the AD DC? *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Wed Feb 5 20:39:00 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 15:39:00 -0500 Subject: [Freeipa-users] ipa AD trust issue In-Reply-To: <52F2762D.2090701@redhat.com> References: <52D9BFD7.30406@redhat.com> <52F2762D.2090701@redhat.com> Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=1061897 *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 12:34 PM, Dmitri Pal wrote: > On 02/04/2014 03:28 PM, Steve Dainard wrote: > > >> >> has anyone worked it out. Secondly cifs-utils has dependency on samba3 >> packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like >> each other , so this is the story of my experience with ipa. Any >> suggestions ? >> >> >> Why do you need cifs-utils on the same server? >> cifs-utils to make a system a client to MSFT file server, AFAIU you cant >> make IPA server to be a cifs client. >> >> > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html > > Step 3 mentions that cifs-utils is required, but: > > yum install cifs-utils > Loaded plugins: product-id, security, subscription-manager > This system is receiving updates from Red Hat Subscription Management. > rhel-6-server-cf-tools-1-rpms | 2.8 kB > 00:00 > rhel-6-server-rhev-agent-rpms | 3.1 kB > 00:00 > rhel-6-server-rpms | 3.7 kB > 00:00 > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed > --> Processing Dependency: libwbclient.so.0()(64bit) for package: > cifs-utils-4.8.1-19.el6.x86_64 > --> Running transaction check > ---> Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be > installed > --> Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: > samba-winbind-clients-3.6.9-167.el6_5.x86_64 > --> Running transaction check > ---> Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed > --> Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: > samba-winbind-3.6.9-167.el6_5.x86_64 > --> Running transaction check > ---> Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed > --> Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts > samba-common < 3.9.9 > --> Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 > conflicts samba-winbind < 3.9.9 > --> Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 > conflicts samba-winbind-clients < 3.9.9 > --> Finished Dependency Resolution > Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 > Error: samba4-winbind-clients conflicts with > samba-winbind-clients-3.6.9-167.el6_5.x86_64 > Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > Is this no longer a requirement? Can this documentation be updated? > > Steve > > > > Can you please file a BZ? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 5 21:09:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Feb 2014 23:09:57 +0200 Subject: [Freeipa-users] Cross domain trust In-Reply-To: References: Message-ID: <20140205210957.GA16904@redhat.com> On Wed, 05 Feb 2014, Steve Dainard wrote: >After the initial setup of a trust I'm attempting to get kerberos tickets >against the AD domain. > >Step 12 in this document: >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: > >Then, request service tickets for services within the Active Directory >domain. >[root at ipaserver ]# kvno cifs/adserver.adexample.com at AD.DOMAIN >If the Active Directory service ticket is succcessfully granted, then there >will be a cross-realm TGT listed with all of the other requested tickets. >This will have the name krbtgt/AD.DOMAIN at IPA.DOMAIN. > >I get an error back: ># kvno cifs/dc1.miovision.corp at MIOVISION.CORP >kvno: Server not found in Kerberos database while getting credentials for >cifs/dc1.miovision.corp at MIOVISION.CORP Can you try 'KRB5_TRACE=/dev/stderr kvno -S cifs dc1.miovision.corp'? Ideally, I'd like to see your /etc/krb5.conf, it should have mapping between AD DNS domain and AD realm so that IPA KDC will be able to route the ticket request properly to the AD DC. Without that it may assume miovision.corp belongs to the IPA realm. > >But I do have a krbtgt ticket/AD domain: > ># klist >Ticket cache: FILE:/tmp/krb5cc_0 >Default principal: sdainard-root at MIOLINUX.CORP > >Valid starting Expires Service principal >02/05/14 14:21:06 02/06/14 14:21:06 krbtgt/MIOLINUX.CORP at MIOLINUX.CORP >02/05/14 14:21:17 02/06/14 14:21:06 host/ipa1.miolinux.corp at MIOLINUX.CORP >02/05/14 14:21:20 02/06/14 14:21:06 krbtgt/MIOVISION.CORP at MIOLINUX.CORP > >Also, is it normal to not find the Linux realm listed in the domain trust >list on the AD DC? It should be listed there. If it is not listed, it means no real trust is established on the AD side. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Feb 5 21:21:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Feb 2014 23:21:02 +0200 Subject: [Freeipa-users] Cross domain trust In-Reply-To: <20140205210957.GA16904@redhat.com> References: <20140205210957.GA16904@redhat.com> Message-ID: <20140205212102.GB16904@redhat.com> On Wed, 05 Feb 2014, Alexander Bokovoy wrote: >On Wed, 05 Feb 2014, Steve Dainard wrote: >>After the initial setup of a trust I'm attempting to get kerberos tickets >>against the AD domain. >> >>Step 12 in this document: >>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: >> >>Then, request service tickets for services within the Active Directory >>domain. >>[root at ipaserver ]# kvno cifs/adserver.adexample.com at AD.DOMAIN >>If the Active Directory service ticket is succcessfully granted, then there >>will be a cross-realm TGT listed with all of the other requested tickets. >>This will have the name krbtgt/AD.DOMAIN at IPA.DOMAIN. >> >>I get an error back: >># kvno cifs/dc1.miovision.corp at MIOVISION.CORP >>kvno: Server not found in Kerberos database while getting credentials for >>cifs/dc1.miovision.corp at MIOVISION.CORP >Can you try 'KRB5_TRACE=/dev/stderr kvno -S cifs dc1.miovision.corp'? > >Ideally, I'd like to see your /etc/krb5.conf, it should have mapping >between AD DNS domain and AD realm so that IPA KDC will be able to route >the ticket request properly to the AD DC. Without that it may assume >miovision.corp belongs to the IPA realm. Actually, that mapping should be generated by sssd in /var/lib/sss/pubconf/krb5.include.d/domain_realm_miolinux_corp -- / Alexander Bokovoy From william.muriithi at gmail.com Wed Feb 5 22:17:29 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 5 Feb 2014 17:17:29 -0500 Subject: [Freeipa-users] Deny SSH access from selected host In-Reply-To: <20140205074355.GG7586@redhat.com> References: <20140205074355.GG7586@redhat.com> Message-ID: >> Would it be possible to deny ssh access per host without pulling a host off >> FreeIPA management? > > from-host part of the rule is not enforced by default due to the fact > that it is pretty easy to fake that one on connection. > > You can try to create more specific rules allowing access to the > systems. With allow_all rule disabled these would help -- when there is > no rule for that user to access an SSH service on the host, it will not > be able to do so. > > Are you using allow_all rule right now? > Yes, the all_allow rule was in place. I didn't see the allow all from the browser though and wasn't aware of it either. After I disabled it, I was able to achieve selective access. Thank you very much. > http://www.freeipa.org/page/Howto/HBAC_and_allow_all > -- > / Alexander Bokovoy William -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Wed Feb 5 22:30:44 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 5 Feb 2014 17:30:44 -0500 Subject: [Freeipa-users] Cross domain trust In-Reply-To: <20140205210957.GA16904@redhat.com> References: <20140205210957.GA16904@redhat.com> Message-ID: I didn't have the firewall on my IPA server down while forming the trust. All seems to be working now. Thanks for your help. Steve > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Thu Feb 6 00:30:16 2014 From: Less at imagine-sw.com (Les Stott) Date: Thu, 6 Feb 2014 00:30:16 +0000 Subject: [Freeipa-users] HBAC - expected behaviour? In-Reply-To: <52F096E7.4090103@redhat.com> References: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> <52F096E7.4090103@redhat.com> Message-ID: <4ED173A868981548967B4FCA270722260649F8@AACMBXP04.exchserver.com> That helps, and I read http://www.freeipa.org/page/Howto/HBAC_and_allow_all Now I understand how it works and the expected behaviour. Thanks. Les -----Original Message----- From: Martin Kosek [mailto:mkosek at redhat.com] Sent: Tuesday, 4 February 2014 6:30 PM To: Les Stott; freeipa-users at redhat.com Subject: Re: [Freeipa-users] HBAC - expected behaviour? On 02/04/2014 05:11 AM, Les Stott wrote: > Hi, > > Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. > > I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. > > # ipa hbacrule-show host1_access > Rule name: host1_access > Description: Only john can access host1 > Enabled: TRUE > Users: john > Hosts: host1.domain.com > Services: sshd > > When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. > > If I access the host "host1" and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. > > # ipa hbacrule-show allow_all > Rule name: allow_all > User category: all > : all > Service category: all > Description: Allow all users to access any host from any host > Enabled: TRUE > Hosts: host2.domain.com, host3.domain.com, host4.domain.com > > Is this how its supposed to be? Or is it a bug in this older version? > I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. > > Thanks, > > Les Hello Les, I am not aware of any recent bugs in HBAC, this is likely a configuration issue. This is how the default HBAC allow_all looks like: # ipa hbacrule-show allow_all Rule name: allow_all User category: all Host category: all <---- : all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE "Host category: all" means that the rule is effective for all hosts. By selectively specifying the hosts, you disabled this selector. Does it help? Martin From barrykfl at gmail.com Thu Feb 6 08:31:49 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Thu, 6 Feb 2014 16:31:49 +0800 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute Message-ID: Hi: I can make it show on ldap browser or the ui but finding where to add it in command base. ipa user-mod ---employeenumber no such parameter. Moreover can i change the attribute just by name and make use of it. E.g. i found car license no really useful for staff so i want to change the label to staff id card number Regards] Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Feb 6 08:35:07 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Feb 2014 09:35:07 +0100 Subject: [Freeipa-users] More SSO Strangeness In-Reply-To: References: Message-ID: <20140206083507.GC2649@localhost.localdomain> On Wed, Feb 05, 2014 at 01:44:13PM -0500, Mark Gardner wrote: > Okay, > > Spent some time on this one... > Some users can login SSO no problem, others have to put in their password. > > Strange as it seems, if the length of the username was greater than 4, the > SSO worked. > So markg at test.local works, but mark at test.local doesn't. Can you send the mapping you use in krb5.conf? Can you check if there are .k5login files in the home directories of the users where SSO is working? bye, Sumit > > My guess is something to do with the NetBios name length? > > Fedora 20 IPA Server > CentOS 6.5 IPA Client > Win 2012 AD Domain Server > > Setup as IPA as a subdomain of AD. > AD Domain: test.local > IPA Domain: hosted.test.local > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbose at redhat.com Thu Feb 6 08:40:10 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Feb 2014 09:40:10 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: References: Message-ID: <20140206084009.GD2649@localhost.localdomain> On Thu, Feb 06, 2014 at 04:31:49PM +0800, barrykfl at gmail.com wrote: > Hi: > > I can make it show on ldap browser or the ui but finding where to add it in > command base. > > ipa user-mod ---employeenumber no such parameter. There is no specific option for employeenumber, but you can set the attribute with ipa user-mod user_name --setattr=employeeNumber=12345 HTH bye, Sumit > > Moreover can i change the attribute just by name and make use of it. > > E.g. i found car license no really useful for staff so i want to change the > label to staff id card number > > Regards] > > Barry > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Thu Feb 6 08:50:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 09:50:04 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: References: Message-ID: <52F34CBC.4030504@redhat.com> On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: > Hi: > > I can make it show on ldap browser or the ui but finding where to add it in > command base. > > ipa user-mod ---employeenumber no such parameter. > > Moreover can i change the attribute just by name and make use of it. > > E.g. i found car license no really useful for staff so i want to change the > label to staff id card number > > Regards] > > Barry > I see we do not offer control of this attribute in our CLI or Web UI. Can you please file us a Trac ticket to add it by default? https://fedorahosted.org/freeipa/ What version of FreeIPA are you using? It should not be difficult though to extend CLI and Web UI with a plugin to add this attribute given that it is already allowed in inetorgperson objectclass. Adding Petr to CC, he can provide you with an example how to add a CLI/UI plugin to make your FreeIPA server show this attribute (UI plugin syntax depending on your FreeIPA version). Martin From pviktori at redhat.com Thu Feb 6 10:59:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 06 Feb 2014 11:59:21 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: References: Message-ID: <52F36B09.1090608@redhat.com> On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: > Hi: > > I can make it show on ldap browser or the ui but finding where to add it > in command base. > > ipa user-mod ---employeenumber no such parameter. You can use setattr where we don't provide specialized CLI arguments. Also note that employeenumber won't show in the default output; you'll want to use --all to retrieve all the attributes. ipa user-mod somerandomuser --setattr=employeenumber=1234 --all ipa user-show somerandomuser --all To add this to the CLI, you would need to modify the user object in your plugin. Something like: from ipalib.plugins import user from ipalib.parameters import Str user.takes_params = user.takes_params + ( Str('employeenumber', cli_name='first', label=_('Employee number'), ), ) > Moreover can i change the attribute just by name and make use of it. > > E.g. i found car license no really useful for staff so i want to change > the label to staff id card number You should ideally create a new LDAP attribute for this, but the label is defined in ipalib.plugins.user. -- Petr? From dpal at redhat.com Thu Feb 6 12:08:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 Feb 2014 07:08:12 -0500 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: <52F36B09.1090608@redhat.com> References: <52F36B09.1090608@redhat.com> Message-ID: <52F37B2C.8090601@redhat.com> On 02/06/2014 05:59 AM, Petr Viktorin wrote: > On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: >> Hi: >> >> I can make it show on ldap browser or the ui but finding where to add it >> in command base. >> >> ipa user-mod ---employeenumber no such parameter. > > You can use setattr where we don't provide specialized CLI arguments. > Also note that employeenumber won't show in the default output; you'll > want to use --all to retrieve all the attributes. > ipa user-mod somerandomuser --setattr=employeenumber=1234 --all > ipa user-show somerandomuser --all > > > To add this to the CLI, you would need to modify the user object in > your plugin. Something like: > > from ipalib.plugins import user > from ipalib.parameters import Str > > user.takes_params = user.takes_params + ( > Str('employeenumber', > cli_name='first', did you mean cli_name='employeenumber' ? Copy paste? > label=_('Employee number'), > ), > ) > >> Moreover can i change the attribute just by name and make use of it. >> >> E.g. i found car license no really useful for staff so i want to change >> the label to staff id card number > > You should ideally create a new LDAP attribute for this, but the label > is defined in ipalib.plugins.user. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Thu Feb 6 12:12:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 06 Feb 2014 13:12:42 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: <52F37B2C.8090601@redhat.com> References: <52F36B09.1090608@redhat.com> <52F37B2C.8090601@redhat.com> Message-ID: <52F37C3A.8020401@redhat.com> On 02/06/2014 01:08 PM, Dmitri Pal wrote: > On 02/06/2014 05:59 AM, Petr Viktorin wrote: >> On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: >>> Hi: >>> >>> I can make it show on ldap browser or the ui but finding where to add it >>> in command base. >>> >>> ipa user-mod ---employeenumber no such parameter. >> >> You can use setattr where we don't provide specialized CLI arguments. >> Also note that employeenumber won't show in the default output; you'll >> want to use --all to retrieve all the attributes. >> ipa user-mod somerandomuser --setattr=employeenumber=1234 --all >> ipa user-show somerandomuser --all >> >> >> To add this to the CLI, you would need to modify the user object in >> your plugin. Something like: >> >> from ipalib.plugins import user >> from ipalib.parameters import Str >> >> user.takes_params = user.takes_params + ( >> Str('employeenumber', >> cli_name='first', > > did you mean > > cli_name='employeenumber' > > > ? > Copy paste? Right, sorry for the mistake. >> label=_('Employee number'), >> ), >> ) >> >>> Moreover can i change the attribute just by name and make use of it. >>> >>> E.g. i found car license no really useful for staff so i want to change >>> the label to staff id card number >> >> You should ideally create a new LDAP attribute for this, but the label >> is defined in ipalib.plugins.user. >> > > -- Petr? From raubvogel at gmail.com Thu Feb 6 14:33:08 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Thu, 6 Feb 2014 09:33:08 -0500 Subject: [Freeipa-users] Specifying gid/uid range Message-ID: Where can I configure the range, or at least starting value, for the uid and gid that will be used when creating user accounts? From chorn at fluxcoil.net Thu Feb 6 14:35:41 2014 From: chorn at fluxcoil.net (Christian Horn) Date: Thu, 6 Feb 2014 15:35:41 +0100 Subject: [Freeipa-users] Specifying gid/uid range In-Reply-To: References: Message-ID: <20140206143540.GA5943@fluxcoil.net> On Thu, Feb 06, 2014 at 09:33:08AM -0500, Mauricio Tavares wrote: > Where can I configure the range, or at least starting value, for > the uid and gid that will be used when creating user accounts? I think this helps: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Managing-Unique_UID_and_GID_Attributes.html Chris From mkosek at redhat.com Thu Feb 6 14:53:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 15:53:58 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: <52F37C3A.8020401@redhat.com> References: <52F36B09.1090608@redhat.com> <52F37B2C.8090601@redhat.com> <52F37C3A.8020401@redhat.com> Message-ID: <52F3A206.1050502@redhat.com> On 02/06/2014 01:12 PM, Petr Viktorin wrote: > On 02/06/2014 01:08 PM, Dmitri Pal wrote: >> On 02/06/2014 05:59 AM, Petr Viktorin wrote: >>> On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: >>>> Hi: >>>> >>>> I can make it show on ldap browser or the ui but finding where to add it >>>> in command base. >>>> >>>> ipa user-mod ---employeenumber no such parameter. >>> >>> You can use setattr where we don't provide specialized CLI arguments. >>> Also note that employeenumber won't show in the default output; you'll >>> want to use --all to retrieve all the attributes. >>> ipa user-mod somerandomuser --setattr=employeenumber=1234 --all >>> ipa user-show somerandomuser --all >>> >>> >>> To add this to the CLI, you would need to modify the user object in >>> your plugin. Something like: >>> >>> from ipalib.plugins import user >>> from ipalib.parameters import Str >>> >>> user.takes_params = user.takes_params + ( >>> Str('employeenumber', >>> cli_name='first', >> >> did you mean >> >> cli_name='employeenumber' >> >> >> ? >> Copy paste? > > Right, sorry for the mistake. Note that you do not need to add this cli_name part of it equals the actual attribute name. cli_name defaults to attribute name. > >>> label=_('Employee number'), >>> ), >>> ) >>> >>>> Moreover can i change the attribute just by name and make use of it. >>>> >>>> E.g. i found car license no really useful for staff so i want to change >>>> the label to staff id card number >>> >>> You should ideally create a new LDAP attribute for this, but the label >>> is defined in ipalib.plugins.user. It seems to me that current employeeNumber attribute present in inetorgperson objectClass is ok for this use case. If yes, then no schema change is needed. Martin From sdainard at miovision.com Thu Feb 6 15:18:36 2014 From: sdainard at miovision.com (Steve Dainard) Date: Thu, 6 Feb 2014 10:18:36 -0500 Subject: [Freeipa-users] Cross domain trust In-Reply-To: References: <20140205210957.GA16904@redhat.com> Message-ID: So I've completed the setup, and can see the trust on the Windows side. I've joined a client to the IPA realm, and can login with a IPA user. When I try to login (console, ssh, su -) as a domain user I get: --------CLIENT SIDE-------- [root at rhel6-client ~]# su - sdainard at miovision su: user sdainard at miovision does not exist [root at rhel6-client ~]# su - sdainard at MIOVISION.CORP su: user sdainard at MIOVISION.CORP does not exist [root at rhel6-client ~]# su - sdainard at miovision.corp su: user sdainard at miovision.corp does not exist [root at rhel6-client ~]# ssh sdainard at miovision@localhost sdainard at miovision@localhost's password: Permission denied, please try again. /var/log/secure: Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): check pass; user unknown Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost Feb 6 10:13:09 rhel6 sshd[2435]: pam_succeed_if(sshd:auth): error retrieving information about user sdainard at miovision Feb 6 10:13:10 rhel6 sshd[2435]: Failed password for invalid user sdainard at miovision from ::1 port 47391 ssh2 Feb 6 10:13:20 rhel6 sshd[2436]: Connection closed by ::1 Feb 6 10:13:25 rhel6 sshd[2709]: Invalid user sdainard at miovision from ::1 Feb 6 10:13:25 rhel6 sshd[2710]: input_userauth_request: invalid user sdainard at miovision Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): check pass; user unknown Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost Feb 6 10:13:38 rhel6 sshd[2709]: pam_succeed_if(sshd:auth): error retrieving information about user sdainard at miovision Feb 6 10:13:40 rhel6 sshd[2709]: Failed password for invalid user sdainard at miovision from ::1 port 47417 ssh2 No logs for sssd; # pwd /var/log/sssd [root at snapshot-test sssd]# ll total 0 -rw-------. 1 root root 0 Feb 5 17:38 krb5_child.log -rw-------. 1 root root 0 Feb 5 17:38 ldap_child.log -rw-------. 1 root root 0 Feb 5 17:37 sssd.log -rw-------. 1 root root 0 Feb 5 17:38 sssd_miolinux.corp.log -rw-------. 1 root root 0 Feb 5 17:38 sssd_nss.log -rw-------. 1 root root 0 Feb 5 17:38 sssd_pac.log -rw-------. 1 root root 0 Feb 5 17:38 sssd_pam.log -rw-------. 1 root root 0 Feb 5 17:38 sssd_ssh.log /etc/sssd/sssd.conf: [domain/miolinux.corp] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = miolinux.corp id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rhel6-client.miolinux.corp chpass_provider = ipa ipa_server = _srv_, ipa1.miolinux.corp ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = miolinux.corp [nss] [pam] [sudo] [autofs] [ssh] [pac] /etc/ipa/default.conf #File modified by ipa-client-install [global] basedn = dc=miolinux,dc=corp realm = MIOLINUX.CORP domain = miolinux.corp server = ipa1.miolinux.corp xmlrpc_uri = https://ipa1.miolinux.corp/ipa/xml enable_ra = True ------------ IPA SERVER SIDE -------------- /var/log/dirsrv/slapd-MIOLINUX-CORP/access * no new entries * /var/log/dirsrv/slapd-MIOLINUX-CORP/errors * no new entries * /var/log/krb5kdc.log when I attempt to su - sdainard at miovision Feb 06 10:08:25 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:08:25 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699305, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:08:26 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699305, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:08:26 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:08:26 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699306, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:08:27 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699306, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:08:27 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:08:27 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699307, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:08:27 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699307, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:08:28 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:08:28 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699308, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:08:28 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699308, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP /var/logkrb5kdc.log when I attempt ssh: Feb 06 10:13:21 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:21 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699601, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:22 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699601, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:22 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:22 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699602, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:23 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699602, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:23 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:23 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699603, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:24 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699603, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:24 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:24 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699604, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:25 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699604, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:25 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: UNKNOWN_SERVER: authtime 0, sdainard at MIOVISION.CORP for host/localhost at MIOLINUX.CORP, Server not found in Kerberos database Feb 06 10:13:25 ipa1.miolinux.corp krb5kdc[7687](info): closing down fd 10 Feb 06 10:13:25 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: UNKNOWN_SERVER: authtime 0, sdainard at MIOVISION.CORP for host/localhost at MIOLINUX.CORP, Server not found in Kerberos database Feb 06 10:13:25 ipa1.miolinux.corp krb5kdc[7689](info): closing down fd 10 Feb 06 10:13:26 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: UNKNOWN_SERVER: authtime 0, sdainard at MIOVISION.CORP for host/localhost at MIOLINUX.CORP, Server not found in Kerberos database Feb 06 10:13:26 ipa1.miolinux.corp krb5kdc[7690](info): closing down fd 10 Feb 06 10:13:30 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:30 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699610, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:30 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699610, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:31 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:31 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699611, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:31 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699611, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:32 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:32 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699612, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:32 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699612, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:32 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:32 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699612, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:33 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699612, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:33 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:33 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699613, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699613, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699614, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699614, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:34 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699614, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:35 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699614, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:35 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:35 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699615, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699615, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699617, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699617, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH: host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP, Additional pre-authentication required Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699618, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for krbtgt/MIOLINUX.CORP at MIOLINUX.CORP Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes {18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699618, etypes {rep=18 tkt=18 ses=18}, host/rhel6-client.miolinux.corp at MIOLINUX.CORP for ldap/ipa1.miolinux.corp at MIOLINUX.CORP *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 5:30 PM, Steve Dainard wrote: > I didn't have the firewall on my IPA server down while forming the trust. > All seems to be working now. > > Thanks for your help. > > Steve > > >> >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 6 16:14:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Feb 2014 18:14:27 +0200 Subject: [Freeipa-users] Cross domain trust In-Reply-To: References: <20140205210957.GA16904@redhat.com> Message-ID: <20140206161427.GN7586@redhat.com> On Thu, 06 Feb 2014, Steve Dainard wrote: >So I've completed the setup, and can see the trust on the Windows side. > >I've joined a client to the IPA realm, and can login with a IPA user. When >I try to login (console, ssh, su -) as a domain user I get: > >--------CLIENT SIDE-------- > >[root at rhel6-client ~]# su - sdainard at miovision >su: user sdainard at miovision does not exist >[root at rhel6-client ~]# su - sdainard at MIOVISION.CORP >su: user sdainard at MIOVISION.CORP does not exist >[root at rhel6-client ~]# su - sdainard at miovision.corp >su: user sdainard at miovision.corp does not exist > > >[root at rhel6-client ~]# ssh sdainard at miovision@localhost >sdainard at miovision@localhost's password: >Permission denied, please try again. > > >/var/log/secure: >Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): check pass; user >unknown >Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): authentication >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost >Feb 6 10:13:09 rhel6 sshd[2435]: pam_succeed_if(sshd:auth): error >retrieving information about user sdainard at miovision >Feb 6 10:13:10 rhel6 sshd[2435]: Failed password for invalid user >sdainard at miovision from ::1 port 47391 ssh2 >Feb 6 10:13:20 rhel6 sshd[2436]: Connection closed by ::1 >Feb 6 10:13:25 rhel6 sshd[2709]: Invalid user sdainard at miovision from ::1 >Feb 6 10:13:25 rhel6 sshd[2710]: input_userauth_request: invalid user >sdainard at miovision >Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): check pass; user >unknown >Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): authentication >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost >Feb 6 10:13:38 rhel6 sshd[2709]: pam_succeed_if(sshd:auth): error >retrieving information about user sdainard at miovision >Feb 6 10:13:40 rhel6 sshd[2709]: Failed password for invalid user >sdainard at miovision from ::1 port 47417 ssh2 Note that there are no logs from sssd above which means sssd never consulted. > >No logs for sssd; ># pwd >/var/log/sssd >[root at snapshot-test sssd]# ll >total 0 >-rw-------. 1 root root 0 Feb 5 17:38 krb5_child.log >-rw-------. 1 root root 0 Feb 5 17:38 ldap_child.log >-rw-------. 1 root root 0 Feb 5 17:37 sssd.log >-rw-------. 1 root root 0 Feb 5 17:38 sssd_miolinux.corp.log >-rw-------. 1 root root 0 Feb 5 17:38 sssd_nss.log >-rw-------. 1 root root 0 Feb 5 17:38 sssd_pac.log >-rw-------. 1 root root 0 Feb 5 17:38 sssd_pam.log >-rw-------. 1 root root 0 Feb 5 17:38 sssd_ssh.log sssd doesn't log if not asked. Each section of /etc/sssd/sssd.conf can have debug_level = line. For more details see sssd.conf(5). > >/etc/sssd/sssd.conf: >[domain/miolinux.corp] > >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = miolinux.corp >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = rhel6-client.miolinux.corp >chpass_provider = ipa >ipa_server = _srv_, ipa1.miolinux.corp >ldap_tls_cacert = /etc/ipa/ca.crt you are missing SSSD configuration for trusts: subdomains_provider = ipa >[sssd] >services = nss, pam, ssh and here also service 'pac' has to be referenced in the 'services = ' line >config_file_version = 2 > >domains = miolinux.corp >[nss] > >[pam] > >[sudo] > >[autofs] > >[ssh] > >[pac] > > > Basically, situation should look like this: 1. IPA master server configured to talk to AD DC, by means of using winbindd in background (on RHEL 6.x, in current Fedora it is done by directly talking to AD LDAP services by SSSD). SSSD on IPA master uses it to resolve IDs for AD users and groups. This requires special setup of SSSD on IPA master, with [domain/...] subdomains_provider = ipa and [sssd] services = ..., pac In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master automatically by setting ipa_master_mode = True On RHEL 6.x one needs to add the parameters manually. 2. /etc/krb5.conf has to contain auth_to_local rules that map AD principals to lower-cased versions because some applications (SSH) are very picky about user/principal name mapping. This has to be done on both IPA masters and IPA clients. 3. On IPA clients SSSD needs to have following in the /etc/sssd/sssd.conf [domain/...] subdomains_provider = ipa and [sssd] services = ..., pac With these changes SSSD on IPA client will recognize AD users and request IPA master to perform name/SID/etc resolution, and also will make an attempt to parse special part of the Kerberos ticket generated by AD DC (MS-PAC) that contains signed cached copy of group ownership for AD users. SSSD needs restart after each config change. You can do checks step by step to see whether things are working: 1. Ensure that SSSD on IPA master resolves AD user properly: getent passwd user at ad.domain Should return non-empty entry. 2. Ensure that SSSD on IPA client resolves AD user properly: getent passwd user at ad.domain Should return non-empty entry. 3. Ensure that Kerberos infrastructure works: kinit user at ad.domain kvno -S host ipa.client.domain 4. Attempt to use Kerberos ticket: ssh -l user at ad.domain ipa.client.domain At this point if everything works fine, SSHd will authenticate user at ad.domain by its Kerberos ticket and authorize its access. -- / Alexander Bokovoy From mkosek at redhat.com Thu Feb 6 16:47:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Feb 2014 17:47:14 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: <52F36B09.1090608@redhat.com> References: <52F36B09.1090608@redhat.com> Message-ID: <52F3BC92.9090405@redhat.com> On 02/06/2014 11:59 AM, Petr Viktorin wrote: > On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: >> Hi: >> >> I can make it show on ldap browser or the ui but finding where to add it >> in command base. >> >> ipa user-mod ---employeenumber no such parameter. > > You can use setattr where we don't provide specialized CLI arguments. > Also note that employeenumber won't show in the default output; you'll want to > use --all to retrieve all the attributes. > ipa user-mod somerandomuser --setattr=employeenumber=1234 --all > ipa user-show somerandomuser --all > > > To add this to the CLI, you would need to modify the user object in your > plugin. Something like: > > from ipalib.plugins import user > from ipalib.parameters import Str > > user.takes_params = user.takes_params + ( > Str('employeenumber', > label=_('Employee number'), > ), > ) > >> Moreover can i change the attribute just by name and make use of it. >> >> E.g. i found car license no really useful for staff so i want to change >> the label to staff id card number > > You should ideally create a new LDAP attribute for this, but the label is > defined in ipalib.plugins.user. > Petr3, can you please also add a Web UI plugin example how to add this field to Web UI user's page to Employee section? Just to have the example complete. Thanks, Martin From sdainard at miovision.com Thu Feb 6 17:23:41 2014 From: sdainard at miovision.com (Steve Dainard) Date: Thu, 6 Feb 2014 12:23:41 -0500 Subject: [Freeipa-users] Cross domain trust In-Reply-To: <20140206161427.GN7586@redhat.com> References: <20140205210957.GA16904@redhat.com> <20140206161427.GN7586@redhat.com> Message-ID: On Thu, Feb 6, 2014 at 11:14 AM, Alexander Bokovoy wrote: > On Thu, 06 Feb 2014, Steve Dainard wrote: > >> So I've completed the setup, and can see the trust on the Windows side. >> >> I've joined a client to the IPA realm, and can login with a IPA user. When >> I try to login (console, ssh, su -) as a domain user I get: >> >> --------CLIENT SIDE-------- >> >> [root at rhel6-client ~]# su - sdainard at miovision >> su: user sdainard at miovision does not exist >> [root at rhel6-client ~]# su - sdainard at MIOVISION.CORP >> su: user sdainard at MIOVISION.CORP does not exist >> [root at rhel6-client ~]# su - sdainard at miovision.corp >> su: user sdainard at miovision.corp does not exist >> >> >> [root at rhel6-client ~]# ssh sdainard at miovision@localhost >> sdainard at miovision@localhost's password: >> Permission denied, please try again. >> >> >> /var/log/secure: >> Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): check pass; user >> unknown >> Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost >> Feb 6 10:13:09 rhel6 sshd[2435]: pam_succeed_if(sshd:auth): error >> retrieving information about user sdainard at miovision >> Feb 6 10:13:10 rhel6 sshd[2435]: Failed password for invalid user >> sdainard at miovision from ::1 port 47391 ssh2 >> Feb 6 10:13:20 rhel6 sshd[2436]: Connection closed by ::1 >> Feb 6 10:13:25 rhel6 sshd[2709]: Invalid user sdainard at miovision from >> ::1 >> Feb 6 10:13:25 rhel6 sshd[2710]: input_userauth_request: invalid user >> sdainard at miovision >> Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): check pass; user >> unknown >> Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost >> Feb 6 10:13:38 rhel6 sshd[2709]: pam_succeed_if(sshd:auth): error >> retrieving information about user sdainard at miovision >> Feb 6 10:13:40 rhel6 sshd[2709]: Failed password for invalid user >> sdainard at miovision from ::1 port 47417 ssh2 >> > Note that there are no logs from sssd above which means sssd never > consulted. > > > >> No logs for sssd; >> # pwd >> /var/log/sssd >> [root at snapshot-test sssd]# ll >> total 0 >> -rw-------. 1 root root 0 Feb 5 17:38 krb5_child.log >> -rw-------. 1 root root 0 Feb 5 17:38 ldap_child.log >> -rw-------. 1 root root 0 Feb 5 17:37 sssd.log >> -rw-------. 1 root root 0 Feb 5 17:38 sssd_miolinux.corp.log >> -rw-------. 1 root root 0 Feb 5 17:38 sssd_nss.log >> -rw-------. 1 root root 0 Feb 5 17:38 sssd_pac.log >> -rw-------. 1 root root 0 Feb 5 17:38 sssd_pam.log >> -rw-------. 1 root root 0 Feb 5 17:38 sssd_ssh.log >> > sssd doesn't log if not asked. Each section of /etc/sssd/sssd.conf can > have debug_level = > line. For more details see sssd.conf(5). > > > >> /etc/sssd/sssd.conf: >> [domain/miolinux.corp] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = miolinux.corp >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = rhel6-client.miolinux.corp >> chpass_provider = ipa >> ipa_server = _srv_, ipa1.miolinux.corp >> ldap_tls_cacert = /etc/ipa/ca.crt >> > you are missing SSSD configuration for trusts: > > subdomains_provider = ipa > > > [sssd] >> services = nss, pam, ssh >> > and here also service 'pac' has to be referenced in the 'services = ' > line > > > config_file_version = 2 >> >> domains = miolinux.corp >> [nss] >> >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> >> >> > Basically, situation should look like this: > > 1. IPA master server configured to talk to AD DC, by means of using > winbindd in > background (on RHEL 6.x, in current Fedora it is done by directly > talking to AD LDAP services by SSSD). SSSD on IPA master uses it to > resolve IDs for AD users > and groups. This requires special setup of SSSD on IPA master, with > > [domain/...] > subdomains_provider = ipa > > and > > [sssd] > services = ..., pac > Server side looks right: [domain/miolinux.corp] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = miolinux.corp id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa1.miolinux.corp chpass_provider = ipa ipa_server = ipa1.miolinux.corp ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa [sssd] services = nss, pam, ssh, pac config_file_version = 2 domains = miolinux.corp [nss] [pam] [sudo] [autofs] [ssh] [pac] > > In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master > automatically by setting ipa_master_mode = True > > On RHEL 6.x one needs to add the parameters manually. > > 2. /etc/krb5.conf has to contain auth_to_local rules that map AD > principals to lower-cased versions because some applications (SSH) > are very picky about user/principal name mapping. This has to be done > on both IPA masters and IPA clients. > This was done on the IPA server, but the RHEL 6.5 client doesn't have this file. On the IPA server: [realms] MIOLINUX.CORP = { kdc = ipa1.miolinux.corp:88 master_kdc = ipa1.miolinux.corp:88 admin_server = ipa1.miolinux.corp:749 default_domain = miolinux.corp pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION$)s/@MIOVISION/@miovision/ auth_to_local = DEFAULT [root at ipa1 ~]# kinit sdainard at miovision.corp Password for sdainard at miovision.corp: kinit: KDC reply did not match expectations while getting initial credentials A CentOS 6.5 client has this file. The docs didn't mention the manual client config, I just assumed the IPA server would proxy the request. After adding, no change. > > 3. On IPA clients SSSD needs to have following in the > /etc/sssd/sssd.conf > > [domain/...] > subdomains_provider = ipa > > and > > [sssd] > services = ..., pac > Added. > > With these changes SSSD on IPA client will recognize AD users and > request IPA master to perform name/SID/etc resolution, and also will > make an attempt to parse special part of the Kerberos ticket > generated by AD DC (MS-PAC) that contains signed cached copy of group > ownership for AD users. > > SSSD needs restart after each config change. > > You can do checks step by step to see whether things are working: > > 1. Ensure that SSSD on IPA master resolves AD user properly: > > getent passwd user at ad.domain > > Should return non-empty entry. > Returns no values. [root at ipa1 ~]# getent passwd sdainard at miovision.corp [root at ipa1 ~]# > > 2. Ensure that SSSD on IPA client resolves AD user properly: > > getent passwd user at ad.domain > > Should return non-empty entry. > [root at snapshot-test ~]# getent passwd sdainard at miovision.corp [root at snapshot-test ~]# > > 3. Ensure that Kerberos infrastructure works: > > kinit user at ad.domain > kvno -S host ipa.client.domain > [root at ipa1 ~]# kinit sdainard at miovision.corp Password for sdainard at miovision.corp: kinit: KDC reply did not match expectations while getting initial credentials [root at ipa1 ~]# kinit sdainard at MIOVISION.CORP Password for sdainard at MIOVISION.CORP: [root at ipa1 ~]# kvno cifs/dc1.miovision.corp at MIOVISION.CORP cifs/dc1.miovision.corp at MIOVISION.CORP: kvno = 41 [root at ipa1 ~]# kvno -S host ipa1.miolinux.corp host/ipa1.miolinux.corp at MIOLINUX.CORP: kvno = 2 [root at ipa1 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: sdainard at MIOVISION.CORP Valid starting Expires Service principal 02/06/14 11:54:55 02/06/14 21:54:57 krbtgt/MIOVISION.CORP at MIOVISION.CORP renew until 02/07/14 11:54:55 02/06/14 11:55:38 02/06/14 21:54:57 cifs/dc1.miovision.corp at MIOVISION.CORP renew until 02/07/14 11:54:55 02/06/14 11:56:50 02/06/14 21:54:57 krbtgt/MIOLINUX.CORP at MIOVISION.CORP renew until 02/07/14 11:54:55 02/06/14 11:57:05 02/06/14 21:54:57 host/ipa1.miolinux.corp at MIOLINUX.CORP renew until 02/07/14 11:54:55 It appears the rewrite rules in krb5.conf are not working, not sure what I missed. > > 4. Attempt to use Kerberos ticket: > > ssh -l user at ad.domain ipa.client.domain > > At this point if everything works fine, SSHd will authenticate > user at ad.domain by its Kerberos ticket and authorize its access. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Feb 6 17:32:38 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Feb 2014 18:32:38 +0100 Subject: [Freeipa-users] HOW to Add employeenumber to user easily? there is account object with emoployee number ttribute In-Reply-To: <52F34CBC.4030504@redhat.com> References: <52F34CBC.4030504@redhat.com> Message-ID: <52F3C736.9050004@redhat.com> On 6.2.2014 09:50, Martin Kosek wrote: > On 02/06/2014 09:31 AM, barrykfl at gmail.com wrote: >> Hi: >> >> I can make it show on ldap browser or the ui but finding where to add it in >> command base. >> >> ipa user-mod ---employeenumber no such parameter. >> >> Moreover can i change the attribute just by name and make use of it. >> >> E.g. i found car license no really useful for staff so i want to change the >> label to staff id card number >> >> Regards] >> >> Barry >> > > I see we do not offer control of this attribute in our CLI or Web UI. Can you > please file us a Trac ticket to add it by default? > > https://fedorahosted.org/freeipa/ > > What version of FreeIPA are you using? It should not be difficult though to > extend CLI and Web UI with a plugin to add this attribute given that it is > already allowed in inetorgperson objectclass. > > Adding Petr to CC, he can provide you with an example how to add a CLI/UI > plugin to make your FreeIPA server show this attribute (UI plugin syntax > depending on your FreeIPA version). > > Martin > Here's the Web UI plugin. Copy the file into /usr/share/ipa/ui/js/plugins/employeenumber directory on FreeIPA server. Note that it should work only with FreeIPA version 3+. It's very difficult to achieve the same result in older version. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: employeenumber.js Type: application/javascript Size: 754 bytes Desc: not available URL: From abokovoy at redhat.com Thu Feb 6 17:42:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Feb 2014 19:42:07 +0200 Subject: [Freeipa-users] Cross domain trust In-Reply-To: References: <20140205210957.GA16904@redhat.com> <20140206161427.GN7586@redhat.com> Message-ID: <20140206174207.GB15418@redhat.com> On Thu, 06 Feb 2014, Steve Dainard wrote: >> In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master >> automatically by setting ipa_master_mode = True >> >> On RHEL 6.x one needs to add the parameters manually. >> >> 2. /etc/krb5.conf has to contain auth_to_local rules that map AD >> principals to lower-cased versions because some applications (SSH) >> are very picky about user/principal name mapping. This has to be done >> on both IPA masters and IPA clients. >> > >This was done on the IPA server, but the RHEL 6.5 client doesn't have this >file. > >On the IPA server: > >[realms] > MIOLINUX.CORP = { > kdc = ipa1.miolinux.corp:88 > master_kdc = ipa1.miolinux.corp:88 > admin_server = ipa1.miolinux.corp:749 > default_domain = miolinux.corp > pkinit_anchors = FILE:/etc/ipa/ca.crt >auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION$)s/@MIOVISION/@miovision/ >auth_to_local = DEFAULT > >[root at ipa1 ~]# kinit sdainard at miovision.corp >Password for sdainard at miovision.corp: >kinit: KDC reply did not match expectations while getting initial >credentials MIT Kerberos is case-sensitive for the realm, so it should always be kinit sdainard at MIOVISION.CORP make also sure that your rule above has proper realm. If your realm is MIOVISION.CORP, then auth_to_local rule is auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION.CORP$)s/@MIOVISION.CORP/@miovision.corp/ In MIT Kerberos 1.13 we'll have an interface that will allow SSSD to automatically generate (and supply) these rules. Prior to that we have to have explicit configuration on all clients and servers. >A CentOS 6.5 client has this file. The docs didn't mention the manual >client config, I just assumed the IPA server would proxy the request. After >adding, no change. A request to IPA server needs to come from a client and a client needs to know about that. We changed SSSD 1.11+ to discover IPA capabilities and self-configure but for older clients (1.9..1.10) you need to perform it through explicit config. >> With these changes SSSD on IPA client will recognize AD users and >> request IPA master to perform name/SID/etc resolution, and also will >> make an attempt to parse special part of the Kerberos ticket >> generated by AD DC (MS-PAC) that contains signed cached copy of group >> ownership for AD users. >> >> SSSD needs restart after each config change. >> >> You can do checks step by step to see whether things are working: >> >> 1. Ensure that SSSD on IPA master resolves AD user properly: >> >> getent passwd user at ad.domain >> >> Should return non-empty entry. >> > >Returns no values. > >[root at ipa1 ~]# getent passwd sdainard at miovision.corp >[root at ipa1 ~]# Can you add debug_level=9 to [domain/...] section in /etc/sssd/sssd.conf, restart sssd and try again? In /var/log/sssd/sssd_.log there will be a lot of debug information that I'd like to see (send it privately). If sssd properly tries to talk to winbindd to resolve id, I'd like to see winbind logs then: # smbcontrol all debug 100 # getent passwd sdainard at miovision.corp # smbcontrol all debug 1 and send me logs from /var/log/samba. > > > > >> >> 2. Ensure that SSSD on IPA client resolves AD user properly: >> >> getent passwd user at ad.domain >> >> Should return non-empty entry. >> > >[root at snapshot-test ~]# getent passwd sdainard at miovision.corp >[root at snapshot-test ~]# > Once we solve it for IPA master, we can continue with this part. > > > >> >> 3. Ensure that Kerberos infrastructure works: >> >> kinit user at ad.domain >> kvno -S host ipa.client.domain >> > >[root at ipa1 ~]# kinit sdainard at miovision.corp >Password for sdainard at miovision.corp: >kinit: KDC reply did not match expectations while getting initial >credentials Expected (realm is case-sensitive). > >[root at ipa1 ~]# kinit sdainard at MIOVISION.CORP >Password for sdainard at MIOVISION.CORP: > >[root at ipa1 ~]# kvno cifs/dc1.miovision.corp at MIOVISION.CORP >cifs/dc1.miovision.corp at MIOVISION.CORP: kvno = 41 > >[root at ipa1 ~]# kvno -S host ipa1.miolinux.corp >host/ipa1.miolinux.corp at MIOLINUX.CORP: kvno = 2 > >[root at ipa1 ~]# klist >Ticket cache: FILE:/tmp/krb5cc_0 >Default principal: sdainard at MIOVISION.CORP > >Valid starting Expires Service principal >02/06/14 11:54:55 02/06/14 21:54:57 krbtgt/MIOVISION.CORP at MIOVISION.CORP > renew until 02/07/14 11:54:55 >02/06/14 11:55:38 02/06/14 21:54:57 cifs/dc1.miovision.corp at MIOVISION.CORP >renew until 02/07/14 11:54:55 >02/06/14 11:56:50 02/06/14 21:54:57 krbtgt/MIOLINUX.CORP at MIOVISION.CORP >renew until 02/07/14 11:54:55 >02/06/14 11:57:05 02/06/14 21:54:57 host/ipa1.miolinux.corp at MIOLINUX.CORP > renew until 02/07/14 11:54:55 Kerberos infrastructure works fine. -- / Alexander Bokovoy From sdainard at miovision.com Thu Feb 6 18:28:51 2014 From: sdainard at miovision.com (Steve Dainard) Date: Thu, 6 Feb 2014 13:28:51 -0500 Subject: [Freeipa-users] Cross domain trust In-Reply-To: <20140206174207.GB15418@redhat.com> References: <20140205210957.GA16904@redhat.com> <20140206161427.GN7586@redhat.com> <20140206174207.GB15418@redhat.com> Message-ID: On Thu, Feb 6, 2014 at 12:42 PM, Alexander Bokovoy wrote: > On Thu, 06 Feb 2014, Steve Dainard wrote: > >> In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master >>> automatically by setting ipa_master_mode = True >>> >>> On RHEL 6.x one needs to add the parameters manually. >>> >>> 2. /etc/krb5.conf has to contain auth_to_local rules that map AD >>> principals to lower-cased versions because some applications (SSH) >>> are very picky about user/principal name mapping. This has to be done >>> on both IPA masters and IPA clients. >>> >>> >> This was done on the IPA server, but the RHEL 6.5 client doesn't have this >> file. >> >> On the IPA server: >> >> [realms] >> MIOLINUX.CORP = { >> kdc = ipa1.miolinux.corp:88 >> master_kdc = ipa1.miolinux.corp:88 >> admin_server = ipa1.miolinux.corp:749 >> default_domain = miolinux.corp >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION$)s/@MIOVISION/@miovision/ >> auth_to_local = DEFAULT >> >> [root at ipa1 ~]# kinit sdainard at miovision.corp >> Password for sdainard at miovision.corp: >> kinit: KDC reply did not match expectations while getting initial >> credentials >> > MIT Kerberos is case-sensitive for the realm, so it should always be > kinit sdainard at MIOVISION.CORP > > make also sure that your rule above has proper realm. If your realm is > MIOVISION.CORP, then auth_to_local rule is > > auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION.CORP$)s/@MIOVISION.CORP/@ > miovision.corp/ > OK that makes sense. I wasn't sure if it was NETBIOS or not. Changed. > > In MIT Kerberos 1.13 we'll have an interface that will allow SSSD to > automatically generate (and supply) these rules. Prior to that we have > to have explicit configuration on all clients and servers. Excellent, do you work with whomever is maintaining the Ubuntu PPA on this as well? One of our dev teams is exclusively on Ubuntu 12.04 and I've had some serious issues with the joining clients from distro. > > > A CentOS 6.5 client has this file. The docs didn't mention the manual >> client config, I just assumed the IPA server would proxy the request. >> After >> adding, no change. >> > A request to IPA server needs to come from a client and a client needs > to know about that. We changed SSSD 1.11+ to discover IPA capabilities > and self-configure but for older clients (1.9..1.10) you need to perform > it through explicit config. > > > With these changes SSSD on IPA client will recognize AD users and >>> request IPA master to perform name/SID/etc resolution, and also will >>> make an attempt to parse special part of the Kerberos ticket >>> generated by AD DC (MS-PAC) that contains signed cached copy of group >>> ownership for AD users. >>> >>> SSSD needs restart after each config change. >>> >>> You can do checks step by step to see whether things are working: >>> >>> 1. Ensure that SSSD on IPA master resolves AD user properly: >>> >>> getent passwd user at ad.domain >>> >>> Should return non-empty entry. >>> >>> >> Returns no values. >> >> [root at ipa1 ~]# getent passwd sdainard at miovision.corp >> [root at ipa1 ~]# >> > Can you add debug_level=9 to [domain/...] section in > /etc/sssd/sssd.conf, restart sssd and try again? > > In /var/log/sssd/sssd_.log there will be a lot of debug > information that I'd like to see (send it privately). > > If sssd properly tries to talk to winbindd to resolve id, I'd like to > see winbind logs then: > > # smbcontrol all debug 100 > # getent passwd sdainard at miovision.corp > # smbcontrol all debug 1 > > and send me logs from /var/log/samba. > > > Done, sending logs outside of list. There are some communications errors. I dropped the firewall on the IPA server to test the last couple runs at 'getent passwd sdainard at MIOVISION.CORP'. > >> >> >> >> >>> 2. Ensure that SSSD on IPA client resolves AD user properly: >>> >>> getent passwd user at ad.domain >>> >>> Should return non-empty entry. >>> >>> >> [root at snapshot-test ~]# getent passwd sdainard at miovision.corp >> [root at snapshot-test ~]# >> >> Once we solve it for IPA master, we can continue with this part. > > > >> >> >> >>> 3. Ensure that Kerberos infrastructure works: >>> >>> kinit user at ad.domain >>> kvno -S host ipa.client.domain >>> >>> >> [root at ipa1 ~]# kinit sdainard at miovision.corp >> Password for sdainard at miovision.corp: >> kinit: KDC reply did not match expectations while getting initial >> credentials >> > Expected (realm is case-sensitive). > > > >> [root at ipa1 ~]# kinit sdainard at MIOVISION.CORP >> Password for sdainard at MIOVISION.CORP: >> >> [root at ipa1 ~]# kvno cifs/dc1.miovision.corp at MIOVISION.CORP >> cifs/dc1.miovision.corp at MIOVISION.CORP: kvno = 41 >> >> [root at ipa1 ~]# kvno -S host ipa1.miolinux.corp >> host/ipa1.miolinux.corp at MIOLINUX.CORP: kvno = 2 >> >> [root at ipa1 ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: sdainard at MIOVISION.CORP >> >> Valid starting Expires Service principal >> 02/06/14 11:54:55 02/06/14 21:54:57 krbtgt/MIOVISION.CORP@ >> MIOVISION.CORP >> renew until 02/07/14 11:54:55 >> 02/06/14 11:55:38 02/06/14 21:54:57 cifs/dc1.miovision.corp@ >> MIOVISION.CORP >> renew until 02/07/14 11:54:55 >> 02/06/14 11:56:50 02/06/14 21:54:57 krbtgt/MIOLINUX.CORP at MIOVISION.CORP >> renew until 02/07/14 11:54:55 >> 02/06/14 11:57:05 02/06/14 21:54:57 host/ipa1.miolinux.corp@ >> MIOLINUX.CORP >> renew until 02/07/14 11:54:55 >> > Kerberos infrastructure works fine. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djablonski at gatessolutions.com Thu Feb 6 18:34:27 2014 From: djablonski at gatessolutions.com (Dave Jablonski) Date: Thu, 6 Feb 2014 12:34:27 -0600 Subject: [Freeipa-users] CentOS 6.5 client install failing Message-ID: FreeIPA Server: Fedora 16, freeipa 2.1.4 Latest CentOS 6.5 client When running: ipa-client-install --mkhomedir --enable-dns-updates The install fails with: trying https:///ipa/xml Forwarding 'env' to server u'https:///ipa/xml' Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2377, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2363, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2167, in install remote_env = api.Command['env'](server=True)['result'] File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 1073, in run return self.forward(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in forward raise error(message=e.faultString) ipalib.errors.CCacheError: did not receive Kerberos credentials In /var/log/ipaclient-install.log: 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = SSLServer 2014-02-06T18:19:53Z DEBUG cert valid True for "CN=,O=" 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server https:///ipa/xml: did not receive Kerberos credentials Any insights or additional info needed just let me know. Thank you. -- IMPORTANT: This e-mail (including any attachments) is intended for the use of the individual or entity to which it is addressed and may contain information that is classified, private, or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 6 18:36:04 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Feb 2014 20:36:04 +0200 Subject: [Freeipa-users] Cross domain trust In-Reply-To: References: <20140205210957.GA16904@redhat.com> <20140206161427.GN7586@redhat.com> <20140206174207.GB15418@redhat.com> Message-ID: <20140206183604.GA16710@redhat.com> On Thu, 06 Feb 2014, Steve Dainard wrote: >On Thu, Feb 6, 2014 at 12:42 PM, Alexander Bokovoy wrote: > >> On Thu, 06 Feb 2014, Steve Dainard wrote: >> >>> In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master >>>> automatically by setting ipa_master_mode = True >>>> >>>> On RHEL 6.x one needs to add the parameters manually. >>>> >>>> 2. /etc/krb5.conf has to contain auth_to_local rules that map AD >>>> principals to lower-cased versions because some applications (SSH) >>>> are very picky about user/principal name mapping. This has to be done >>>> on both IPA masters and IPA clients. >>>> >>>> >>> This was done on the IPA server, but the RHEL 6.5 client doesn't have this >>> file. >>> >>> On the IPA server: >>> >>> [realms] >>> MIOLINUX.CORP = { >>> kdc = ipa1.miolinux.corp:88 >>> master_kdc = ipa1.miolinux.corp:88 >>> admin_server = ipa1.miolinux.corp:749 >>> default_domain = miolinux.corp >>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>> auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION$)s/@MIOVISION/@miovision/ >>> auth_to_local = DEFAULT >>> >>> [root at ipa1 ~]# kinit sdainard at miovision.corp >>> Password for sdainard at miovision.corp: >>> kinit: KDC reply did not match expectations while getting initial >>> credentials >>> >> MIT Kerberos is case-sensitive for the realm, so it should always be >> kinit sdainard at MIOVISION.CORP >> >> make also sure that your rule above has proper realm. If your realm is >> MIOVISION.CORP, then auth_to_local rule is >> >> auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION.CORP$)s/@MIOVISION.CORP/@ >> miovision.corp/ >> > >OK that makes sense. I wasn't sure if it was NETBIOS or not. Changed. It is realm, always, since krb5.conf rules deal with principal names. >> In MIT Kerberos 1.13 we'll have an interface that will allow SSSD to >> automatically generate (and supply) these rules. Prior to that we have >> to have explicit configuration on all clients and servers. > > >Excellent, do you work with whomever is maintaining the Ubuntu PPA on this >as well? One of our dev teams is exclusively on Ubuntu 12.04 and I've had >some serious issues with the joining clients from distro. Talk to Timo Aaltonen (Canonical) who maintains FreeIPA bits in Ubuntu (and Debian). I believe he is on the list. In any way, MIT 1.13 will be due this year and for sure will not be available on Ubuntu 12.04 so you'll need to make sure there is a delivery process for configuration management at your site (puppet, etc) that will distribute proper krb5.conf and sssd.conf changes. >Done, sending logs outside of list. > >There are some communications errors. I dropped the firewall on the IPA >server to test the last couple runs at 'getent passwd >sdainard at MIOVISION.CORP'. Ok, waiting. -- / Alexander Bokovoy From shreerajkarulkar at yahoo.com Fri Feb 7 02:33:14 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Thu, 6 Feb 2014 18:33:14 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC Message-ID: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> First of all, the?ipa-replica-install did not allow me to use the?--setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except? 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run?ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at? ipa ? ? ? ? : DEBUG ? ?stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com'?while getting initial credentials ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From maleko42 at gmail.com Fri Feb 7 11:55:17 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Fri, 7 Feb 2014 06:55:17 -0500 Subject: [Freeipa-users] Fwd: More SSO Strangeness In-Reply-To: References: <20140206083507.GC2649@localhost.localdomain> <20140206141603.GH2649@localhost.localdomain> <20140206164735.GI2649@localhost.localdomain> <20140206172025.GK2649@localhost.localdomain> Message-ID: ---------- Forwarded message ---------- From: Mark Gardner Date: Thu, Feb 6, 2014 at 12:29 PM Subject: Re: [Freeipa-users] More SSO Strangeness To: Sumit Bose Bingo! I checked my AD user login name which was mark at TEST.LOCAL, But the Pre Win2000 name was TEST\Mark Changed to TEST\mark, logged out of WinClient, then back in and into ipa client with successful SSO. Thanks!!! On Thu, Feb 6, 2014 at 12:20 PM, Sumit Bose wrote: > On Thu, Feb 06, 2014 at 12:04:24PM -0500, Mark Gardner wrote: > > Using username "mark at test.local". > > Unauthorized access is prohibited. > > mark at test.local@ipaclient.hosted.test.local's password: > > Last login: Thu Feb 6 12:00:50 2014 from server2012.test.local > > Authorized uses only. All activity may be monitored and reported. > > -sh-4.1$ klist > > Ticket cache: FILE:/tmp/krb5cc_1063801109_S3Ew2U > > Default principal: mark at TEST.LOCAL > > > > Valid starting Expires Service principal > > 02/06/14 12:03:18 02/06/14 22:02:37 krbtgt/TEST.LOCAL at TEST.LOCAL > > renew until 02/07/14 12:03:18 > > > > sorry, I meant the credentials on the Windows client where you call > putty. > > bye, > Sumit > > > > > > > On Thu, Feb 6, 2014 at 11:47 AM, Sumit Bose wrote: > > > > > On Thu, Feb 06, 2014 at 10:56:31AM -0500, Mark Gardner wrote: > > > > getent passwd mark at test.local worked > > > > > > > > Here's the ssh info from /var/log/secure > > > > > > > > > > > > > > > > > > ... > > > > > > > Feb 6 10:50:03 ipaclient sshd[1623]: debug3: mm_request_receive > entering > > > > Feb 6 10:50:03 ipaclient sshd[1622]: debug3: monitor_read: checking > > > > request 42 > > > > Feb 6 10:50:03 ipaclient sshd[1622]: debug3: mm_answer_gss_userok: > > > sending > > > > result 0 > > > > Feb 6 10:50:03 ipaclient sshd[1622]: debug3: mm_request_send > entering: > > > > type 43 > > > > Feb 6 10:50:03 ipaclient sshd[1623]: debug3: mm_ssh_gssapi_userok: > user > > > > not authenticated > > > > Feb 6 10:50:03 ipaclient sshd[1623]: debug3: Wrote 96 bytes for a > total > > > of > > > > 2869 > > > > Feb 6 10:50:03 ipaclient sshd[1622]: Failed gssapi-with-mic for > > > > mark at test.local from 192.168.100.145 port 60426 ssh2 > > > > Feb 6 10:50:03 ipaclient sshd[1622]: debug3: mm_request_receive > entering > > > > Feb 6 10:50:08 ipaclient sshd[1623]: debug1: userauth-request for > user > > > > mark at test.local service ssh-connection method password > > > > > > are you sure that you are using the right credentials? According to the > > > log you are using putty. Have you logged in as 'mark' on the Windows > > > client? Please call klist in a command window and check thar your > > > Kerberos principal is 'mark at TEST.LOCAL' > > > > > > bye, > > > Sumit > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Feb 8 09:29:34 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 8 Feb 2014 10:29:34 +0100 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <20140208092932.GA11564@mail.corp.redhat.com> On (06/02/14 18:33), Shree wrote: >First of all, the?ipa-replica-install did not allow me to use the?--setup-ca > option complaining that a cert already exists, replicate creation was > successful after I skipped the option. >Seems like the replica is one except? >1) There is no CA Service running on the replica (which I guess is expected) >and >2) I am unable to run?ipa-client-install successfully on any clients using > the replica. (I don't have the option of using the primary master as it is > configured in a segregated environment. Only the master and replica are > allowed to sync. >Debug shows it fails at? > >ipa ? ? ? ? : DEBUG ? ?stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com'?while getting initial credentials > > I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS From raubvogel at gmail.com Sat Feb 8 13:34:51 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sat, 8 Feb 2014 08:34:51 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp Message-ID: Even though I already have a ntp server, I setup my newly created freeipa kdc to do that too (it is a slave to my primary ntp). I then build a centos host to be the test client. Just to make sure it can see and use auth's ntp, I tested with ntpdate: [root at centos64 ~]# ntpdate auth 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset -0.003097 sec [root at centos64 ~]# so far so good, so how about running ipa-client-install? [root at centos64 ~]# hostname centos64 [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` Discovery was successful! Hostname: centos64.in.domain.com Realm: DOMAIN.COM DNS Domain: domain.com IPA Server: auth.in.domain.com BaseDN: dc=domain,dc=com [so far so good!] Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Password for admin at DOMAIN.COM: But, it had not problems using ntpdate against auth. to add insult to injury, the log claims it is using ntpdate: 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com 2014-02-08T13:14:31Z DEBUG stdout= 2014-02-08T13:14:31Z DEBUG stderr= 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Could it be it is pissed because it was in sync to begin with? I mean, if we run the exact command the log file claims to have run, [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| echo $? 0 [root at centos64 ~]# We see it was successful. I am feeling rather clueless here... From rcritten at redhat.com Sat Feb 8 13:48:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 08 Feb 2014 14:48:21 +0100 Subject: [Freeipa-users] CentOS 6.5 client install failing In-Reply-To: References: Message-ID: <52F635A5.3040609@redhat.com> Dave Jablonski wrote: > FreeIPA Server: Fedora 16, freeipa 2.1.4 > Latest CentOS 6.5 client > > When running: > > ipa-client-install --mkhomedir --enable-dns-updates > > The install fails with: > > trying https:///ipa/xml > Forwarding 'env' to server u'https:///ipa/xml' > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2377, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2363, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2167, in install > remote_env = api.Command['env'](server=True)['result'] > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 1073, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, > in forward > return self.Backend.xmlclient.forward(self.name , > *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in > forward > raise error(message=e.faultString) > ipalib.errors.CCacheError: did not receive Kerberos credentials > > In /var/log/ipaclient-install.log: > > 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = > SSLServer > 2014-02-06T18:19:53Z DEBUG cert valid True for "CN=,O=" > 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 > > 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server > https:///ipa/xml: did not receive Kerberos credentials We need to see more context from the client install log, preferably the whole thing. IPA v2 doesn't support session cookies but the 3.x client should have support for falling back to using TGT delegation. rob From shreerajkarulkar at yahoo.com Sat Feb 8 16:14:53 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Sat, 8 Feb 2014 08:14:53 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <20140208092932.GA11564@mail.corp.redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> Message-ID: <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The "replica" got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about "Cannot contact any KDC for realm". I am wondering it my hosts in the new network are trying to access the "master" for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? ? At this point I cannot disable or ?move the master, it needs to function in its location but I need? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik wrote: On (06/02/14 18:33), Shree wrote: >First of all, the?ipa-replica-install did not allow me to use the?--setup-ca > option complaining that a cert already exists, replicate creation was > successful after I skipped the option. >Seems like the replica is one except? >1) There is no CA Service running on the replica (which I guess is expected) >and >2) I am unable to run?ipa-client-install successfully on any clients using > the replica. (I don't have the option of using the primary master as it is > configured in a segregated environment. Only the master and replica are > allowed to sync. >Debug shows it fails at? > >ipa ? ? ? ? : DEBUG ? ?stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com'?while getting initial credentials > > I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sun Feb 9 12:44:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 09 Feb 2014 13:44:05 +0100 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <52F77815.1060100@redhat.com> Shree wrote: > Lukas > Perhaps I should explain the design a bit and see if FreeIPA even > supports this.Our replica is in a separate network and all the > appropriate ports are opened between the master and the replica. The > "replica" got created successfully and is in sync with the master > (except the CA services which I mentioned earlier) > Now,when I try to run ipa-client-install on hosts in the new network > using the replica, it complains that about "Cannot contact any KDC for > realm". > I am wondering it my hosts in the new network are trying to access the > "master" for certificates since the replica does not have any CA > services running? I couldn't find any obvious proof of this even running > the install in a debug mode. Do I need to open ports between the new > hosts and the master for CA services? > At this point I cannot disable or move the master, it needs to function > in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik > wrote: > On (06/02/14 18:33), Shree wrote: > > >First of all, the ipa-replica-install did not allow me to use > the --setup-ca > > option complaining that a cert already exists, replicate creation was > > successful after I skipped the option. > >Seems like the replica is one except > >1) There is no CA Service running on the replica (which I guess is > expected) > >and > >2) I am unable to run ipa-client-install successfully on any clients using > > the replica. (I don't have the option of using the primary master as > it is > > configured in a segregated environment. Only the master and replica are > > allowed to sync. > >Debug shows it fails at > > > >ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm > 'mydomainname.com' while getting initial credentials > > > > > > > I was not able to install replica witch CA on fedora 20, > Bug is already reported https://fedorahosted.org/pki/ticket/816 > > Guys from dogtag found a workaround > https://fedorahosted.org/pki/ticket/816#comment:12 > > Does it work for you? > > LS > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From william.muriithi at gmail.com Sun Feb 9 21:13:50 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 9 Feb 2014 16:13:50 -0500 Subject: [Freeipa-users] sudo 'run as' question Message-ID: Afternoon, I have an application that use the account image as service account. I can su to the account 'image' and start or stop it fine. No root privilege needed. So I am not trying to set it up so that other developers can be able to restart it through sudo and that's when I realized I am missing something about sudo. The problem is under "run as" usage. When I look at man page, it imply that "run as" account don't need to be root. Quoting the man page. Begin quote: sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. End quote: On FreeIPA, I have a sudo rule called developers with necessary hostgroups and usergroups. At the bottom is a section titled "AS WHOM" and that's where I am having a problem. If I use root under RunAs Users section, it works. If I substitute root with account image, I get the following error. [william at dev18-yyz-int ~]$ sudo service imageserver stop [sudo] password for william: Sorry, user william is not allowed to execute '/sbin/service imageserver stop' as root on dev18-yyz-int.jamar.loc. [william at dev18-yyz-int ~]$ ls -al /etc/init.d/imageserver -rwxr-xr-x. 1 image image 1014 Jan 9 15:38 /etc/init.d/imageserver [william at dev18-yyz-int ~]$ cat /etc/init.d/imageserver #! /bin/sh start(){ echo "Starting imageserver.." eval "runuser - image -c '/usr/local/bin/imageserver.sh &'" } stop(){ echo "Stopping imageserver.." PIDNUMBER=`ps aux | grep imaginserver | grep -v grep | awk '{print $2}'` echo $PIDNUMBER eval "runuser - image -c 'kill -9 $PIDNUMBER'" } [william at dev18-yyz-int ~]$ ls -al /usr/local/bin/imageserver.sh -rwxr--r--. 1 image image 89 Jan 9 15:36 /usr/local/bin/imageserver.sh [williamm at dev18-yyz-int ~]$ cat /usr/local/bin/imageserver.sh #!/bin/bash cd /opt/jamar/application/imaginserver nohup ant run > /dev/null 2>&1 & Is it possible to use sudo without first needing to go through root momentary. I suspect this should be possible as sudo "run as" facility wouldn't then make sense otherwise . So, it would work as follows: William -> image Instead of: William -> root -> image. Appreciate any advice in advance William -------------- next part -------------- An HTML attachment was scrubbed... URL: From stbenjam at redhat.com Sun Feb 9 21:35:13 2014 From: stbenjam at redhat.com (Stephen Benjamin) Date: Sun, 9 Feb 2014 16:35:13 -0500 (EST) Subject: [Freeipa-users] sudo 'run as' question In-Reply-To: References: Message-ID: <1299298707.1021030.1391981713127.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "William Muriithi" > To: freeipa-users at redhat.com > Sent: Sunday, February 9, 2014 10:13:50 PM > Subject: [Freeipa-users] sudo 'run as' question > > Afternoon, > > I have an application that use the account image as service account. I can > su to the account 'image' and start or stop it fine. No root privilege > needed. So I am not trying to set it up so that other developers can be > able to restart it through sudo and that's when I realized I am missing > something about sudo. > > The problem is under "run as" usage. When I look at man page, it imply that > "run as" account don't need to be root. Quoting the man page. > > Begin quote: > sudo allows a permitted user to execute a command as the superuser or > another user, as specified by the security policy. End quote: > > On FreeIPA, I have a sudo rule called developers with necessary hostgroups > and usergroups. At the bottom is a section titled "AS WHOM" and that's > where I am having a problem. If I use root under RunAs Users section, it > works. If I substitute root with account image, I get the following error. > > [william at dev18-yyz-int ~]$ sudo service imageserver stop > [sudo] password for william: > Sorry, user william is not allowed to execute '/sbin/service imageserver > stop' as root on dev18-yyz-int.jamar.loc. You need to specify the user, because the default for sudo is root. sudo -u image Although, this won't work - your init script is using runuser, which an unprivileged user can't use. HTH. Stephen From Steven.Jones at vuw.ac.nz Mon Feb 10 00:28:36 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 10 Feb 2014 00:28:36 +0000 Subject: [Freeipa-users] user cronjobs In-Reply-To: <1299298707.1021030.1391981713127.JavaMail.zimbra@redhat.com> References: , <1299298707.1021030.1391981713127.JavaMail.zimbra@redhat.com> Message-ID: <719df9c641424956acc7613069f6d071@SINPR04MB298.apcprd04.prod.outlook.com> Hi, When I patch IPA to RHEL6.5 from 6.4 I will have them down for about 30mins while I snapshot them in vmware. Would userland cronjobs fail if IPA isnt available? regards Steven From sdainard at miovision.com Mon Feb 10 02:07:10 2014 From: sdainard at miovision.com (Steve Dainard) Date: Sun, 9 Feb 2014 21:07:10 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: References: Message-ID: I've noticed if ntpd is already running on the client when you run the ipa-client-install, you will get that error. I'm guessing its using ntpdate IP ADDRESS to sync time, and cannot do so when the daemon is running. *Steve * On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares wrote: > Even though I already have a ntp server, I setup my newly > created freeipa kdc to do that too (it is a slave to my primary ntp). > > I then build a centos host to be the test client. Just to make sure it > can see and use auth's ntp, I tested with ntpdate: > > [root at centos64 ~]# ntpdate auth > 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset > -0.003097 sec > [root at centos64 ~]# > > so far so good, so how about running ipa-client-install? > > [root at centos64 ~]# hostname > centos64 > [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` > Discovery was successful! > Hostname: centos64.in.domain.com > Realm: DOMAIN.COM > DNS Domain: domain.com > IPA Server: auth.in.domain.com > BaseDN: dc=domain,dc=com > > [so far so good!] > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > Password for admin at DOMAIN.COM: > > But, it had not problems using ntpdate against auth. to add insult to > injury, the log claims it is using ntpdate: > > 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v > auth.in.domain.com > 2014-02-08T13:14:31Z DEBUG stdout= > 2014-02-08T13:14:31Z DEBUG stderr= > 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, > assuming the time is in sync. Please check that 123 UDP port is > opened. > > Could it be it is pissed because it was in sync to begin with? I mean, > if we run the exact command the log file claims to have run, > > [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| > echo $? > 0 > [root at centos64 ~]# > > We see it was successful. > > I am feeling rather clueless here... > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raubvogel at gmail.com Mon Feb 10 02:52:48 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sun, 9 Feb 2014 21:52:48 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: References: Message-ID: On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard wrote: > I've noticed if ntpd is already running on the client when you run the > ipa-client-install, you will get that error. I'm guessing its using ntpdate > IP ADDRESS to sync time, and cannot do so when the daemon is running. > > I've noticed if ntpd is already running on the client when you run the > ipa-client-install, you will get that error. I'm guessing its using ntpdate > IP ADDRESS to sync time, and cannot do so when the daemon is running. > Now that you mentioned that I would agree with you in that it is failing because ntpd is running already; I could not see it because of the option "-s" in [root at centos64 ~]# service ntpd status ntpd (pid 3721) is running... [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com [root at centos64 ~]# I could not find what all of those arguments mean in the centos 6.5 ntpdate man page, but here is what I found under ubuntu's: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. -s Divert logging output from the standard output (default) to the system syslog facility. This is designed primarily for conve? nience of cron scripts. -v Be verbose. This option will cause ntpdate's version identifica? tion string to be logged. In other words, -s is sending the output to syslog. And, if we check /var/log/messages we will find that Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting as you expected. Now, how did it detect the ntpdate failed? > Steve > > > On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares > wrote: >> >> Even though I already have a ntp server, I setup my newly >> created freeipa kdc to do that too (it is a slave to my primary ntp). >> >> I then build a centos host to be the test client. Just to make sure it >> can see and use auth's ntp, I tested with ntpdate: >> >> [root at centos64 ~]# ntpdate auth >> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset >> -0.003097 sec >> [root at centos64 ~]# >> >> so far so good, so how about running ipa-client-install? >> >> [root at centos64 ~]# hostname >> centos64 >> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` >> Discovery was successful! >> Hostname: centos64.in.domain.com >> Realm: DOMAIN.COM >> DNS Domain: domain.com >> IPA Server: auth.in.domain.com >> BaseDN: dc=domain,dc=com >> >> [so far so good!] >> >> Continue to configure the system with these values? [no]: yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP server, assuming the time is in sync. >> Please check that 123 UDP port is opened. >> Password for admin at DOMAIN.COM: >> >> But, it had not problems using ntpdate against auth. to add insult to >> injury, the log claims it is using ntpdate: >> >> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v >> auth.in.domain.com >> 2014-02-08T13:14:31Z DEBUG stdout= >> 2014-02-08T13:14:31Z DEBUG stderr= >> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, >> assuming the time is in sync. Please check that 123 UDP port is >> opened. >> >> Could it be it is pissed because it was in sync to begin with? I mean, >> if we run the exact command the log file claims to have run, >> >> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| >> echo $? >> 0 >> [root at centos64 ~]# >> >> We see it was successful. >> >> I am feeling rather clueless here... >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From mkosek at redhat.com Mon Feb 10 07:46:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 08:46:02 +0100 Subject: [Freeipa-users] user cronjobs In-Reply-To: <719df9c641424956acc7613069f6d071@SINPR04MB298.apcprd04.prod.outlook.com> References: , <1299298707.1021030.1391981713127.JavaMail.zimbra@redhat.com> <719df9c641424956acc7613069f6d071@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <52F883BA.5080704@redhat.com> On 02/10/2014 01:28 AM, Steven Jones wrote: > Hi, > > When I patch IPA to RHEL6.5 from 6.4 I will have them down for about 30mins while I snapshot them in vmware. Would userland cronjobs fail if IPA isnt available? > > regards > > Steven I am not sure about the question - depends on the cronjob. If you kinit in the cronjob and there will be no IPA running, then yes - the cronjobs will fail. But if you have properly set IPA Kerberos DNS SRV records and do not shut down all IPAs at once, kinit on cronjobs should just fallback to other IPA. Martin From mkosek at redhat.com Mon Feb 10 10:03:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 11:03:43 +0100 Subject: [Freeipa-users] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones Message-ID: <52F8A3FF.10200@redhat.com> Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) "Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) "Pilsner" -> "Future releases" (with appropriate milestone description to set the expectations right) b) "Beer Exchange" -> "Backlog" (with better description) c) "Deferred" - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From barrykfl at gmail.com Mon Feb 10 11:01:31 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Mon, 10 Feb 2014 19:01:31 +0800 Subject: [Freeipa-users] export user info Message-ID: Dear all: Which command can export /show all users a/c and info? better in table format . Regards Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Feb 10 11:39:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Feb 2014 12:39:57 +0100 Subject: [Freeipa-users] export user info In-Reply-To: References: Message-ID: <52F8BA8D.5030103@redhat.com> On 02/10/2014 12:01 PM, barrykfl at gmail.com wrote: > Dear all: > > Which command can export /show all users a/c and info? better in table > format . > > Regards > > Barry $ ipa user-find Or in JSON-RPC command: {"method":"user_find","params":[[""],{"sizelimit":0}]} Martin From sdainard at miovision.com Mon Feb 10 15:55:33 2014 From: sdainard at miovision.com (Steve Dainard) Date: Mon, 10 Feb 2014 10:55:33 -0500 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts Message-ID: I've setup RHEL 7 beta IPA with a trust to an AD domain. When I use an AD domain login it takes roughly 9-14 seconds to get to a shell after entering a password. Is there any way to speed this process up? I thought supplemental logins would be quicker, but the login time is the same. This is either via console, or via ssh at localhost or ssh over the network. IPA realm = miolinux.corp DC domain/forest = miovision.corp /etc/sssd/sssd_miolinux.corp.log it looks like there is a 5-6 second delay when checking for subdomains: (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: login (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: tty1 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 9 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 9988 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [cc_residual_is_used] (0x1000): User [799001323] is still active, reusing ccache [/tmp/krb5cc_799001323_zWaW2Z]. (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [check_for_valid_tgt] (0x0020): krb5_cc_retrieve_cred failed. (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa1.miolinux.corp' is 'working' (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 508 (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.miolinux.corp' (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [krb5_find_ccache_step] (0x0080): Saved ccache FILE:/tmp/krb5cc_799001323_zWaW2Z if of different type than ccache in configuration file, reusing the old ccache (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Feb 10 10:17:30 2014) [sssd[be[miolinux.corp]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][MIOVISION] *(Mon Feb 10 10:17:30 2014) [sssd[be[miolinux.corp]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, ) [Success]* *(Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] (0x0400): EOF received, client finished* It then looks to take another 3-4 seconds to resolve group membership. I've highlighted an error as well 'user lookup failed': (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][3][45]. (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][24]. (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): TGT times are [1392045449][1392045449][1392081449][1392131849]. (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa1.miolinux.corp' as 'working' (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'working' (Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the same, no one will be deleted. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [10018]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0100): child [10018] finished successfully. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. *(Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed* (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: login (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: tty1 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 9988 (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_access_send] (0x0400): Performing access check for user [sdainard at miovision.corp] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [sdainard at miovision.corp] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=snapshot-test.miolinux.corp))][cn=accounts,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostname] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp] using OpenLDAP deref (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [ipa_hostgroup_info_done] (0x0200): No host groups were dereferenced (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_service_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACService)] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACService)][cn=hbac,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_servicegroup_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACServiceGroup)] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACServiceGroup)][cn=hbac,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))][cn=hbac,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [hbac_eval_user_element] (0x1000): No groups for [sdainard at miovision.corp] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [seeAlso] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUser] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Mon Feb 10 10:17:37 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=sdainard] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: login (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: tty1 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 9988 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: login (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: tty1 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 9988 (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799001323] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=miolinux,dc=corp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=799001323)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=miolinux,dc=corp]. (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results. (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory) (Mon Feb 10 10:17:38 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success I've read that the method of determining AD group membership is expected to take a while, but is this normal? Thanks, *Steve * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 10 16:09:00 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 10 Feb 2014 17:09:00 +0100 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts In-Reply-To: References: Message-ID: <20140210160900.GA2635@localhost.localdomain> On Mon, Feb 10, 2014 at 10:55:33AM -0500, Steve Dainard wrote: > I've setup RHEL 7 beta IPA with a trust to an AD domain. > > When I use an AD domain login it takes roughly 9-14 seconds to get to a > shell after entering a password. Is there any way to speed this process up? > I thought supplemental logins would be quicker, but the login time is the > same. This is either via console, or via ssh at localhost or ssh over the > network. at a first glace I would say that the delay is in krb5_child. Can you send this log file as well? bye, Sumit > > IPA realm = miolinux.corp > DC domain/forest = miovision.corp > ... > (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] > (0x0400): All data has been sent! ... > *(Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] > (0x0400): EOF received, client finished* > From sdainard at miovision.com Mon Feb 10 19:08:22 2014 From: sdainard at miovision.com (Steve Dainard) Date: Mon, 10 Feb 2014 14:08:22 -0500 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts In-Reply-To: <20140210160900.GA2635@localhost.localdomain> References: <20140210160900.GA2635@localhost.localdomain> Message-ID: Sure: (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [main] (0x0400): krb5_child started. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdainard at MIOVISION.CORP] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [main] (0x0400): krb5_child started. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdainard at MIOVISION.CORP] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929]]]] [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [main] (0x0400): krb5_child started. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdainard at MIOVISION.CORP] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [main] (0x0400): krb5_child started. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdainard at MIOVISION.CORP] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:17:30 2014) [[sssd[krb5_child[10018]]]] [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018]]]] [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018]]]] [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018]]]] [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018]]]] [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018]]]] [main] (0x0400): krb5_child completed successfully *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 10, 2014 at 11:09 AM, Sumit Bose wrote: > On Mon, Feb 10, 2014 at 10:55:33AM -0500, Steve Dainard wrote: > > I've setup RHEL 7 beta IPA with a trust to an AD domain. > > > > When I use an AD domain login it takes roughly 9-14 seconds to get to a > > shell after entering a password. Is there any way to speed this process > up? > > I thought supplemental logins would be quicker, but the login time is the > > same. This is either via console, or via ssh at localhost or ssh over the > > network. > > at a first glace I would say that the delay is in krb5_child. Can you > send this log file as well? > > bye, > Sumit > > > > > IPA realm = miolinux.corp > > DC domain/forest = miovision.corp > > > > ... > > > (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] > > (0x0400): All data has been sent! > > ... > > > *(Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] > > (0x0400): EOF received, client finished* > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Feb 10 20:32:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:32:53 -0500 Subject: [Freeipa-users] CentOS 6.5 client install failing In-Reply-To: <52F635A5.3040609@redhat.com> References: <52F635A5.3040609@redhat.com> Message-ID: <52F93775.7050209@redhat.com> On 02/08/2014 08:48 AM, Rob Crittenden wrote: > Dave Jablonski wrote: >> FreeIPA Server: Fedora 16, freeipa 2.1.4 >> Latest CentOS 6.5 client >> >> When running: >> >> ipa-client-install --mkhomedir --enable-dns-updates >> >> The install fails with: >> >> trying https:///ipa/xml >> Forwarding 'env' to server u'https:///ipa/xml' >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 2377, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 2363, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 2167, in install >> remote_env = api.Command['env'](server=True)['result'] >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, >> in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> 1073, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, >> in forward >> return self.Backend.xmlclient.forward(self.name , >> *args, **kw) >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in >> forward >> raise error(message=e.faultString) >> ipalib.errors.CCacheError: did not receive Kerberos credentials >> >> In /var/log/ipaclient-install.log: >> >> 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = >> SSLServer >> 2014-02-06T18:19:53Z DEBUG cert valid True for >> "CN=,O=" >> 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 >> >> 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server >> https:///ipa/xml: did not receive Kerberos credentials > > We need to see more context from the client install log, preferably > the whole thing. > > IPA v2 doesn't support session cookies but the 3.x client should have > support for falling back to using TGT delegation. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Any chance to upgrade the server to something more modern? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Feb 10 20:37:09 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:37:09 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52F77815.1060100@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> Message-ID: <52F93875.60504@redhat.com> On 02/09/2014 07:44 AM, Rob Crittenden wrote: > Shree wrote: >> Lukas >> Perhaps I should explain the design a bit and see if FreeIPA even >> supports this.Our replica is in a separate network and all the >> appropriate ports are opened between the master and the replica. The >> "replica" got created successfully and is in sync with the master >> (except the CA services which I mentioned earlier) >> Now,when I try to run ipa-client-install on hosts in the new network >> using the replica, it complains that about "Cannot contact any KDC for >> realm". >> I am wondering it my hosts in the new network are trying to access the >> "master" for certificates since the replica does not have any CA >> services running? I couldn't find any obvious proof of this even running >> the install in a debug mode. Do I need to open ports between the new >> hosts and the master for CA services? >> At this point I cannot disable or move the master, it needs to function >> in its location but I need > > No, the clients don't directly talk to the CA. > > You'd need to look in /var/log/ipaclient-install.log to see what KDC > was found and we were trying to use. If you have SRV records for both > but we try to contact the hidden master this will happen. You can try > specifying the server on the command-line with --server but this will > be hardcoding things and make it less flexible later. > > rob > >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> >> Change is the only Constant ! >> >> >> On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik >> wrote: >> On (06/02/14 18:33), Shree wrote: >> >> >First of all, the ipa-replica-install did not allow me to use >> the --setup-ca >> > option complaining that a cert already exists, replicate creation was >> > successful after I skipped the option. >> >Seems like the replica is one except >> >1) There is no CA Service running on the replica (which I guess is >> expected) >> >and >> >2) I am unable to run ipa-client-install successfully on any clients >> using >> > the replica. (I don't have the option of using the primary master as >> it is >> > configured in a segregated environment. Only the master and replica >> are >> > allowed to sync. >> >Debug shows it fails at >> > >> >ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm >> 'mydomainname.com' while getting initial credentials >> >> > >> > >> >> I was not able to install replica witch CA on fedora 20, >> Bug is already reported https://fedorahosted.org/pki/ticket/816 >> >> Guys from dogtag found a workaround >> https://fedorahosted.org/pki/ticket/816#comment:12 >> >> Does it work for you? >> >> LS >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What server provides DNS capabilities to the clients? Do you use IPA DNS or some other DNS? Clients seem to not be able to see replica KDC and try to access hidden master but they can know about this master only via DNS. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Feb 10 20:40:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Feb 2014 15:40:12 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: References: Message-ID: <52F9392C.6080303@redhat.com> On 02/09/2014 09:52 PM, Mauricio Tavares wrote: > On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard wrote: >> I've noticed if ntpd is already running on the client when you run the >> ipa-client-install, you will get that error. I'm guessing its using ntpdate >> IP ADDRESS to sync time, and cannot do so when the daemon is running. >> >> I've noticed if ntpd is already running on the client when you run the >> ipa-client-install, you will get that error. I'm guessing its using ntpdate >> IP ADDRESS to sync time, and cannot do so when the daemon is running. >> > Now that you mentioned that I would agree with you in that it is > failing because ntpd is running already; I could not see it because of > the option "-s" in > > [root at centos64 ~]# service ntpd status > ntpd (pid 3721) is running... > [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com > [root at centos64 ~]# > > I could not find what all of those arguments mean in the centos 6.5 > ntpdate man page, but here is what I found under ubuntu's: > > -b Force the time to be stepped using the settimeofday() system > call, rather than slewed (default) using the adjtime() system > call. This option should be used when called from a startup file > at boot time. > > -s Divert logging output from the standard output (default) to the > system syslog facility. This is designed primarily for conve? > nience of cron scripts. > > -v Be verbose. This option will cause ntpdate's version identifica? > tion string to be logged. > > In other words, -s is sending the output to syslog. And, if we check > /var/log/messages we will find that > > Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting > > as you expected. Now, how did it detect the ntpdate failed? > >> Steve >> >> >> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares >> wrote: >>> Even though I already have a ntp server, I setup my newly >>> created freeipa kdc to do that too (it is a slave to my primary ntp). >>> >>> I then build a centos host to be the test client. Just to make sure it >>> can see and use auth's ntp, I tested with ntpdate: >>> >>> [root at centos64 ~]# ntpdate auth >>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset >>> -0.003097 sec >>> [root at centos64 ~]# >>> >>> so far so good, so how about running ipa-client-install? >>> >>> [root at centos64 ~]# hostname >>> centos64 >>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` >>> Discovery was successful! >>> Hostname: centos64.in.domain.com >>> Realm: DOMAIN.COM >>> DNS Domain: domain.com >>> IPA Server: auth.in.domain.com >>> BaseDN: dc=domain,dc=com >>> >>> [so far so good!] >>> >>> Continue to configure the system with these values? [no]: yes >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>> Please check that 123 UDP port is opened. >>> Password for admin at DOMAIN.COM: >>> >>> But, it had not problems using ntpdate against auth. to add insult to >>> injury, the log claims it is using ntpdate: >>> >>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v >>> auth.in.domain.com >>> 2014-02-08T13:14:31Z DEBUG stdout= >>> 2014-02-08T13:14:31Z DEBUG stderr= >>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, >>> assuming the time is in sync. Please check that 123 UDP port is >>> opened. >>> >>> Could it be it is pissed because it was in sync to begin with? I mean, >>> if we run the exact command the log file claims to have run, >>> >>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| >>> echo $? >>> 0 >>> [root at centos64 ~]# >>> >>> We see it was successful. >>> >>> I am feeling rather clueless here... >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users This sounds like a bug to me but I would wait for European gurus to chime in the morning. If it is a bug we need a ticket. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From raubvogel at gmail.com Mon Feb 10 21:08:45 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 10 Feb 2014 16:08:45 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: <52F9392C.6080303@redhat.com> References: <52F9392C.6080303@redhat.com> Message-ID: On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal wrote: > On 02/09/2014 09:52 PM, Mauricio Tavares wrote: >> >> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard >> wrote: >>> >>> I've noticed if ntpd is already running on the client when you run the >>> ipa-client-install, you will get that error. I'm guessing its using >>> ntpdate >>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>> >>> I've noticed if ntpd is already running on the client when you run the >>> ipa-client-install, you will get that error. I'm guessing its using >>> ntpdate >>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>> >> Now that you mentioned that I would agree with you in that it is >> failing because ntpd is running already; I could not see it because of >> the option "-s" in >> >> [root at centos64 ~]# service ntpd status >> ntpd (pid 3721) is running... >> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com >> [root at centos64 ~]# >> >> I could not find what all of those arguments mean in the centos 6.5 >> ntpdate man page, but here is what I found under ubuntu's: >> >> -b Force the time to be stepped using the settimeofday() >> system >> call, rather than slewed (default) using the adjtime() >> system >> call. This option should be used when called from a startup >> file >> at boot time. >> >> -s Divert logging output from the standard output (default) to >> the >> system syslog facility. This is designed primarily for >> conve? >> nience of cron scripts. >> >> -v Be verbose. This option will cause ntpdate's version >> identifica? >> tion string to be logged. >> >> In other words, -s is sending the output to syslog. And, if we check >> /var/log/messages we will find that >> >> Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting >> >> as you expected. Now, how did it detect the ntpdate failed? >> >>> Steve >>> >>> >>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares >>> wrote: >>>> >>>> Even though I already have a ntp server, I setup my newly >>>> created freeipa kdc to do that too (it is a slave to my primary ntp). >>>> >>>> I then build a centos host to be the test client. Just to make sure it >>>> can see and use auth's ntp, I tested with ntpdate: >>>> >>>> [root at centos64 ~]# ntpdate auth >>>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset >>>> -0.003097 sec >>>> [root at centos64 ~]# >>>> >>>> so far so good, so how about running ipa-client-install? >>>> >>>> [root at centos64 ~]# hostname >>>> centos64 >>>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` >>>> Discovery was successful! >>>> Hostname: centos64.in.domain.com >>>> Realm: DOMAIN.COM >>>> DNS Domain: domain.com >>>> IPA Server: auth.in.domain.com >>>> BaseDN: dc=domain,dc=com >>>> >>>> [so far so good!] >>>> >>>> Continue to configure the system with these values? [no]: yes >>>> User authorized to enroll computers: admin >>>> Synchronizing time with KDC... >>>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>>> Please check that 123 UDP port is opened. >>>> Password for admin at DOMAIN.COM: >>>> >>>> But, it had not problems using ntpdate against auth. to add insult to >>>> injury, the log claims it is using ntpdate: >>>> >>>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v >>>> auth.in.domain.com >>>> 2014-02-08T13:14:31Z DEBUG stdout= >>>> 2014-02-08T13:14:31Z DEBUG stderr= >>>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, >>>> assuming the time is in sync. Please check that 123 UDP port is >>>> opened. >>>> >>>> Could it be it is pissed because it was in sync to begin with? I mean, >>>> if we run the exact command the log file claims to have run, >>>> >>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| >>>> echo $? >>>> 0 >>>> [root at centos64 ~]# >>>> >>>> We see it was successful. >>>> >>>> I am feeling rather clueless here... >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > This sounds like a bug to me but I would wait for European gurus to chime in > the morning. > If it is a bug we need a ticket. > I dunno where to file a ticket but here is my suggestion: in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def synconce_ntp(server_fqdn): replace cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn] with cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", server_fqdn] Reasoning: [root at centos64 ~]# date +%T -s "10:13:13" 10:13:13 [root at centos64 ~]# date Mon Feb 10 10:13:15 EST 2014 [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth [root at centos64 ~]# date Mon Feb 10 16:05:49 EST 2014 [root at centos64 ~]# service ntpd status ntpd (pid 8870) is running... [root at centos64 ~]# > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From djablonski at gatessolutions.com Mon Feb 10 23:51:26 2014 From: djablonski at gatessolutions.com (Dave Jablonski) Date: Mon, 10 Feb 2014 17:51:26 -0600 Subject: [Freeipa-users] CentOS 6.5 client install failing In-Reply-To: <52F93775.7050209@redhat.com> References: <52F635A5.3040609@redhat.com> <52F93775.7050209@redhat.com> Message-ID: Unfortunately no. I don't have access to the server. On Feb 10, 2014 2:36 PM, "Dmitri Pal" wrote: > On 02/08/2014 08:48 AM, Rob Crittenden wrote: > >> Dave Jablonski wrote: >> >>> FreeIPA Server: Fedora 16, freeipa 2.1.4 >>> Latest CentOS 6.5 client >>> >>> When running: >>> >>> ipa-client-install --mkhomedir --enable-dns-updates >>> >>> The install fails with: >>> >>> trying https:///ipa/xml >>> Forwarding 'env' to server u'https:///ipa/xml' >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-client-install", line 2377, in >>> sys.exit(main()) >>> File "/usr/sbin/ipa-client-install", line 2363, in main >>> rval = install(options, env, fstore, statestore) >>> File "/usr/sbin/ipa-client-install", line 2167, in install >>> remote_env = api.Command['env'](server=True)['result'] >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, >>> in __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >>> 1073, in run >>> return self.forward(*args, **options) >>> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, >>> in forward >>> return self.Backend.xmlclient.forward(self.name , >>> *args, **kw) >>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in >>> forward >>> raise error(message=e.faultString) >>> ipalib.errors.CCacheError: did not receive Kerberos credentials >>> >>> In /var/log/ipaclient-install.log: >>> >>> 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage = >>> SSLServer >>> 2014-02-06T18:19:53Z DEBUG cert valid True for >>> "CN=,O=" >>> 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443 >>> >>> 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server >>> https:///ipa/xml: did not receive Kerberos credentials >>> >> >> We need to see more context from the client install log, preferably the >> whole thing. >> >> IPA v2 doesn't support session cookies but the 3.x client should have >> support for falling back to using TGT delegation. >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > Any chance to upgrade the server to something more modern? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- IMPORTANT: This e-mail (including any attachments) is intended for the use of the individual or entity to which it is addressed and may contain information that is classified, private, or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Mon Feb 10 18:46:42 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Mon, 10 Feb 2014 10:46:42 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52F77815.1060100@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> Message-ID: <1392058002.89545.YahooMailNeo@web160105.mail.bf1.yahoo.com> Lucas (sorry my previous email may have got sent improperly edited. My typical command looks like this (domain name changed due to disclosure reasons) # ipa-client-install --domain=mydomain.com?--server=ldap2.mydomain.com?--hostname=test500.mydomain.com?-d master = ldap.mydomain.com replica = ldap2.mydomain.com I ran lsof while running a ipa-client-install and found the following "kinit" instances trying to access my "master" ===================== ipa-clien 10443 ? ? ?root ?mem ? ? ? REG ? ? ? ? ? ? ?253,0 ? 334040 ? ?1704353 /lib64/libldap_r-2.4.so.2.5.6 ipa-clien 10443 ? ? ?root ?mem ? ? ? REG ? ? ? ? ? ? ?253,0 ? ?61896 ? ?1444372 /usr/lib64/python2.6/site-packages/_ldap.so kinit ? ? 10545 ? ? ?root ? ?3u ? ? IPv4 ? ? ? ? ? ? 143621 ? ? ?0t0 ? ? ? ?UDP test500.mydomain.com:57166->ldap.mydomain.com:kerberos kinit ? ? 10545 ? ? ?root ? ?4u ? ? IPv4 ? ? ? ? ? ? 143636 ? ? ?0t0 ? ? ? ?TCP test500.mydomain.com:35574->ldap.mydomain.com:kerberos (SYN_SENT) ===================== the client install also finds issue with syncing time during client install, but only gives warning. The time difference between master and client is within seconds. ? the client install also finds issue with? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Sunday, February 9, 2014 4:44 AM, Rob Crittenden wrote: Shree wrote: > Lukas > Perhaps I should explain the design a bit and see if FreeIPA even > supports this.Our replica is in a separate network and all the > appropriate ports are opened between the master and the replica. The > "replica" got created successfully and is in sync with the master > (except the CA services which I mentioned earlier) > Now,when I try to run ipa-client-install on hosts in the new network > using the replica, it complains that about "Cannot contact any KDC for > realm". > I am wondering it my hosts in the new network are trying to access the > "master" for certificates since the replica does not have any CA > services running? I couldn't find any obvious proof of this even running > the install in a debug mode. Do I need to open ports between the new > hosts and the master for CA services? > At this point I cannot disable or? move the master, it needs to function > in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik > wrote: > On (06/02/14 18:33), Shree wrote: > >? >First of all, the ipa-replica-install did not allow me to use > the --setup-ca >? > option complaining that a cert already exists, replicate creation was >? > successful after I skipped the option. >? >Seems like the replica is one except >? >1) There is no CA Service running on the replica (which I guess is > expected) >? >and >? >2) I am unable to run ipa-client-install successfully on any clients using >? > the replica. (I don't have the option of using the primary master as > it is >? > configured in a segregated environment. Only the master and replica are >? > allowed to sync. >? >Debug shows it fails at >? > >? >ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot contact any KDC for realm > 'mydomainname.com' while getting initial credentials > >? > >? > > > I was not able to install replica witch CA on fedora 20, > Bug is already reported https://fedorahosted.org/pki/ticket/816 > > Guys from dogtag found a workaround > https://fedorahosted.org/pki/ticket/816#comment:12 > > Does it work for you? > > LS > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Tue Feb 11 02:07:03 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 11 Feb 2014 10:07:03 +0800 Subject: [Freeipa-users] Upgrade of Free ipa in CENTOS 6 Message-ID: Dear all: Any one have exp to upgrade ipa-server-3.0.0-26.el6_4.4.x86_64 to ipa-server-3.0.0-37.el6_4.4.x86_64 ( jus t minor patch/upgrade it think ) Is it just yum install then ok ??? i notice some official document but they are 3.3 free ipa of fedora ...just yum / run the rpm and not necessary shut down. Is it same in CENTOS ipa 3.0 server one ? http://www.freeipa.org/page/Releases/3.2.0#Upgrading -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at altosresearch.com Tue Feb 11 06:02:53 2014 From: steve at altosresearch.com (Steve Severance) Date: Mon, 10 Feb 2014 22:02:53 -0800 Subject: [Freeipa-users] Free-IPA in an AWS Base Image Message-ID: I want to create an AWS AMI that when it starts up will register itself with a Free-IPA instance. The issue I have run into so far is every instance when it starts up uses the original instances hostname. What do I need to do to have free-ipa work in a DHCP environment like this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 11 08:40:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 09:40:30 +0100 Subject: [Freeipa-users] Free-IPA in an AWS Base Image In-Reply-To: References: Message-ID: <52F9E1FE.5090508@redhat.com> On 02/11/2014 07:02 AM, Steve Severance wrote: > I want to create an AWS AMI that when it starts up will register itself > with a Free-IPA instance. The issue I have run into so far is every > instance when it starts up uses the original instances hostname. What do I > need to do to have free-ipa work in a DHCP environment like this? That's a good question. AWS is not really a friendly environment for Kerberos based IdM solution, especially the changing hostname part. There are procedures and workarounds to make it running, but it still has some sharp edges. You can find the most information in a great blog post by our user [1] or in an upstream ticket [2] which should improve the situation in next releases. Martin [1] http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html [2] https://fedorahosted.org/freeipa/ticket/3961 From c.schmitt at envisia.de Tue Feb 11 09:05:37 2014 From: c.schmitt at envisia.de (Christian Schmitt) Date: Tue, 11 Feb 2014 10:05:37 +0100 Subject: [Freeipa-users] Problems with NetworkManager and FreeIPA Users Message-ID: <8008852.bvssPGMvHY@schmitch.envisia.de> Hello, currently I have installed a IPA Server (CentOS 6.5) and have a Fedora 20 Heisenburg Client with ipa installed. Currently I have some strange problems with every user account from free IPA. They can't change the NetworkManager settings on the KDE Gui, like open a WLAN connection or connect to a VPN. The NetworkManager (nm-applet from KDE) has a Red X Icon in front and if i click on it there is only a message like "NetworkManager 0.9.8 required, found". If I open a shell and enter: > $ nm-connection-editor I get the following errors: > ** (nm-connection-editor:17166): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; type="method_call", sender=":1.81" (uid=977800001 pid=17166 comm="nm- connection-editor ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=733 comm="/usr/sbin/NetworkManager --no-daemon ") > ** (nm-connection-editor:17166): WARNING **: _nm_remote_settings_ensure_inited: (NMRemoteSettings) error initializing: Rejected send message, 3 matched rules; type="method_call", sender=":1.81" (uid=977800001 pid=17166 comm="nm-connection-editor ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=733 comm="/usr/sbin/NetworkManager --no-daemon ") This is somehow really strange and looks like some DBus error. But currently The user is in the user group wheel, and local users working perfectly? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mkosek at redhat.com Tue Feb 11 09:12:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Feb 2014 10:12:50 +0100 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: References: <52F9392C.6080303@redhat.com> Message-ID: <52F9E992.90704@redhat.com> On 02/10/2014 10:08 PM, Mauricio Tavares wrote: > On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal wrote: >> On 02/09/2014 09:52 PM, Mauricio Tavares wrote: >>> >>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard >>> wrote: >>>> >>>> I've noticed if ntpd is already running on the client when you run the >>>> ipa-client-install, you will get that error. I'm guessing its using >>>> ntpdate >>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>>> >>>> I've noticed if ntpd is already running on the client when you run the >>>> ipa-client-install, you will get that error. I'm guessing its using >>>> ntpdate >>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>>> >>> Now that you mentioned that I would agree with you in that it is >>> failing because ntpd is running already; I could not see it because of >>> the option "-s" in >>> >>> [root at centos64 ~]# service ntpd status >>> ntpd (pid 3721) is running... >>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com >>> [root at centos64 ~]# >>> >>> I could not find what all of those arguments mean in the centos 6.5 >>> ntpdate man page, but here is what I found under ubuntu's: >>> >>> -b Force the time to be stepped using the settimeofday() >>> system >>> call, rather than slewed (default) using the adjtime() >>> system >>> call. This option should be used when called from a startup >>> file >>> at boot time. >>> >>> -s Divert logging output from the standard output (default) to >>> the >>> system syslog facility. This is designed primarily for >>> conve? >>> nience of cron scripts. >>> >>> -v Be verbose. This option will cause ntpdate's version >>> identifica? >>> tion string to be logged. >>> >>> In other words, -s is sending the output to syslog. And, if we check >>> /var/log/messages we will find that >>> >>> Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting >>> >>> as you expected. Now, how did it detect the ntpdate failed? >>> >>>> Steve >>>> >>>> >>>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares >>>> wrote: >>>>> >>>>> Even though I already have a ntp server, I setup my newly >>>>> created freeipa kdc to do that too (it is a slave to my primary ntp). >>>>> >>>>> I then build a centos host to be the test client. Just to make sure it >>>>> can see and use auth's ntp, I tested with ntpdate: >>>>> >>>>> [root at centos64 ~]# ntpdate auth >>>>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset >>>>> -0.003097 sec >>>>> [root at centos64 ~]# >>>>> >>>>> so far so good, so how about running ipa-client-install? >>>>> >>>>> [root at centos64 ~]# hostname >>>>> centos64 >>>>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` >>>>> Discovery was successful! >>>>> Hostname: centos64.in.domain.com >>>>> Realm: DOMAIN.COM >>>>> DNS Domain: domain.com >>>>> IPA Server: auth.in.domain.com >>>>> BaseDN: dc=domain,dc=com >>>>> >>>>> [so far so good!] >>>>> >>>>> Continue to configure the system with these values? [no]: yes >>>>> User authorized to enroll computers: admin >>>>> Synchronizing time with KDC... >>>>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>>>> Please check that 123 UDP port is opened. >>>>> Password for admin at DOMAIN.COM: >>>>> >>>>> But, it had not problems using ntpdate against auth. to add insult to >>>>> injury, the log claims it is using ntpdate: >>>>> >>>>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v >>>>> auth.in.domain.com >>>>> 2014-02-08T13:14:31Z DEBUG stdout= >>>>> 2014-02-08T13:14:31Z DEBUG stderr= >>>>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, >>>>> assuming the time is in sync. Please check that 123 UDP port is >>>>> opened. >>>>> >>>>> Could it be it is pissed because it was in sync to begin with? I mean, >>>>> if we run the exact command the log file claims to have run, >>>>> >>>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| >>>>> echo $? >>>>> 0 >>>>> [root at centos64 ~]# >>>>> >>>>> We see it was successful. >>>>> >>>>> I am feeling rather clueless here... >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> This sounds like a bug to me but I would wait for European gurus to chime in >> the morning. >> If it is a bug we need a ticket. >> > I dunno where to file a ticket but here is my suggestion: > > in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def > synconce_ntp(server_fqdn): > > replace > > cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn] > > with > > cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", server_fqdn] > > Reasoning: > > [root at centos64 ~]# date +%T -s "10:13:13" > 10:13:13 > [root at centos64 ~]# date > Mon Feb 10 10:13:15 EST 2014 > [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth > [root at centos64 ~]# date > Mon Feb 10 16:05:49 EST 2014 > [root at centos64 ~]# service ntpd status > ntpd (pid 8870) is running... > [root at centos64 ~]# Just to close the loop - this is the filed Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1063512 I will clone it upstream so that we can triage it. Martin From jhrozek at redhat.com Tue Feb 11 10:18:51 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Feb 2014 11:18:51 +0100 Subject: [Freeipa-users] Problems with NetworkManager and FreeIPA Users In-Reply-To: <8008852.bvssPGMvHY@schmitch.envisia.de> References: <8008852.bvssPGMvHY@schmitch.envisia.de> Message-ID: <20140211101851.GD6125@hendrix.redhat.com> On Tue, Feb 11, 2014 at 10:05:37AM +0100, Christian Schmitt wrote: > Hello, currently I have installed a IPA Server (CentOS 6.5) and have a Fedora > 20 Heisenburg Client with ipa installed. > > Currently I have some strange problems with every user account from free IPA. > They can't change the NetworkManager settings on the KDE Gui, like open a WLAN > connection or connect to a VPN. > > The NetworkManager (nm-applet from KDE) has a Red X Icon in front and if i > click on it there is only a message like "NetworkManager 0.9.8 required, > found". > > If I open a shell and enter: > > > $ nm-connection-editor > > I get the following errors: > > > ** (nm-connection-editor:17166): WARNING **: Could not initialize NMClient > /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; > type="method_call", sender=":1.81" (uid=977800001 pid=17166 comm="nm- > connection-editor ") interface="org.freedesktop.DBus.Properties" > member="GetAll" error name="(unset)" requested_reply="0" > destination="org.freedesktop.NetworkManager" (uid=0 pid=733 > comm="/usr/sbin/NetworkManager --no-daemon ") > > ** (nm-connection-editor:17166): WARNING **: > _nm_remote_settings_ensure_inited: (NMRemoteSettings) error initializing: > Rejected send message, 3 matched rules; type="method_call", sender=":1.81" > (uid=977800001 pid=17166 comm="nm-connection-editor ") > interface="org.freedesktop.DBus.Properties" member="GetAll" error > name="(unset)" requested_reply="0" > destination="org.freedesktop.NetworkManager" (uid=0 pid=733 > comm="/usr/sbin/NetworkManager --no-daemon ") > > This is somehow really strange and looks like some DBus error. But currently > The user is in the user group wheel, and local users working perfectly? Looking at the NM DBus config at /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf it seems that most rules including the org.freedesktop.DBus.Properties interface are allowed for console users (with policy at_console="true"). Typically, the console user is identified by pam_console. Can you check if the login manager you used has pam_console in the session stack? From raubvogel at gmail.com Tue Feb 11 11:46:24 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Tue, 11 Feb 2014 06:46:24 -0500 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: <52F9E992.90704@redhat.com> References: <52F9392C.6080303@redhat.com> <52F9E992.90704@redhat.com> Message-ID: On Feb 11, 2014 4:12 AM, "Martin Kosek" wrote: > > On 02/10/2014 10:08 PM, Mauricio Tavares wrote: > > On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal wrote: > >> On 02/09/2014 09:52 PM, Mauricio Tavares wrote: > >>> > >>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard > >>> wrote: > >>>> > >>>> I've noticed if ntpd is already running on the client when you run the > >>>> ipa-client-install, you will get that error. I'm guessing its using > >>>> ntpdate > >>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. > >>>> > >>>> I've noticed if ntpd is already running on the client when you run the > >>>> ipa-client-install, you will get that error. I'm guessing its using > >>>> ntpdate > >>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. > >>>> > >>> Now that you mentioned that I would agree with you in that it is > >>> failing because ntpd is running already; I could not see it because of > >>> the option "-s" in > >>> > >>> [root at centos64 ~]# service ntpd status > >>> ntpd (pid 3721) is running... > >>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com > >>> [root at centos64 ~]# > >>> > >>> I could not find what all of those arguments mean in the centos 6.5 > >>> ntpdate man page, but here is what I found under ubuntu's: > >>> > >>> -b Force the time to be stepped using the settimeofday() > >>> system > >>> call, rather than slewed (default) using the adjtime() > >>> system > >>> call. This option should be used when called from a startup > >>> file > >>> at boot time. > >>> > >>> -s Divert logging output from the standard output (default) to > >>> the > >>> system syslog facility. This is designed primarily for > >>> conve? > >>> nience of cron scripts. > >>> > >>> -v Be verbose. This option will cause ntpdate's version > >>> identifica? > >>> tion string to be logged. > >>> > >>> In other words, -s is sending the output to syslog. And, if we check > >>> /var/log/messages we will find that > >>> > >>> Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting > >>> > >>> as you expected. Now, how did it detect the ntpdate failed? > >>> > >>>> Steve > >>>> > >>>> > >>>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares > >>>> wrote: > >>>>> > >>>>> Even though I already have a ntp server, I setup my newly > >>>>> created freeipa kdc to do that too (it is a slave to my primary ntp). > >>>>> > >>>>> I then build a centos host to be the test client. Just to make sure it > >>>>> can see and use auth's ntp, I tested with ntpdate: > >>>>> > >>>>> [root at centos64 ~]# ntpdate auth > >>>>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset > >>>>> -0.003097 sec > >>>>> [root at centos64 ~]# > >>>>> > >>>>> so far so good, so how about running ipa-client-install? > >>>>> > >>>>> [root at centos64 ~]# hostname > >>>>> centos64 > >>>>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` > >>>>> Discovery was successful! > >>>>> Hostname: centos64.in.domain.com > >>>>> Realm: DOMAIN.COM > >>>>> DNS Domain: domain.com > >>>>> IPA Server: auth.in.domain.com > >>>>> BaseDN: dc=domain,dc=com > >>>>> > >>>>> [so far so good!] > >>>>> > >>>>> Continue to configure the system with these values? [no]: yes > >>>>> User authorized to enroll computers: admin > >>>>> Synchronizing time with KDC... > >>>>> Unable to sync time with IPA NTP server, assuming the time is in sync. > >>>>> Please check that 123 UDP port is opened. > >>>>> Password for admin at DOMAIN.COM: > >>>>> > >>>>> But, it had not problems using ntpdate against auth. to add insult to > >>>>> injury, the log claims it is using ntpdate: > >>>>> > >>>>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v > >>>>> auth.in.domain.com > >>>>> 2014-02-08T13:14:31Z DEBUG stdout= > >>>>> 2014-02-08T13:14:31Z DEBUG stderr= > >>>>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server, > >>>>> assuming the time is in sync. Please check that 123 UDP port is > >>>>> opened. > >>>>> > >>>>> Could it be it is pissed because it was in sync to begin with? I mean, > >>>>> if we run the exact command the log file claims to have run, > >>>>> > >>>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com| > >>>>> echo $? > >>>>> 0 > >>>>> [root at centos64 ~]# > >>>>> > >>>>> We see it was successful. > >>>>> > >>>>> I am feeling rather clueless here... > >>>>> > >>>>> _______________________________________________ > >>>>> Freeipa-users mailing list > >>>>> Freeipa-users at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > >>>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> > >> This sounds like a bug to me but I would wait for European gurus to chime in > >> the morning. > >> If it is a bug we need a ticket. > >> > > I dunno where to file a ticket but here is my suggestion: > > > > in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def > > synconce_ntp(server_fqdn): > > > > replace > > > > cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn] > > > > with > > > > cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", server_fqdn] > > > > Reasoning: > > > > [root at centos64 ~]# date +%T -s "10:13:13" > > 10:13:13 > > [root at centos64 ~]# date > > Mon Feb 10 10:13:15 EST 2014 > > [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth > > [root at centos64 ~]# date > > Mon Feb 10 16:05:49 EST 2014 > > [root at centos64 ~]# service ntpd status > > ntpd (pid 8870) is running... > > [root at centos64 ~]# > > Just to close the loop - this is the filed Bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063512 > > I will clone it upstream so that we can triage it. Sorry. I didn't know I could submit a patch and how. It's already impressive I did the bugzilla thing. I can also do the patch, but would it then be redundant? > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Feb 11 12:07:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Feb 2014 13:07:42 +0100 Subject: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp In-Reply-To: References: <52F9392C.6080303@redhat.com> <52F9E992.90704@redhat.com> Message-ID: <52FA128E.2010508@redhat.com> On 11.2.2014 12:46, Mauricio Tavares wrote: > On Feb 11, 2014 4:12 AM, "Martin Kosek" wrote: >> >> On 02/10/2014 10:08 PM, Mauricio Tavares wrote: >>> On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal wrote: >>>> On 02/09/2014 09:52 PM, Mauricio Tavares wrote: >>>>> >>>>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard >>>>> wrote: >>>>>> >>>>>> I've noticed if ntpd is already running on the client when you run > the >>>>>> ipa-client-install, you will get that error. I'm guessing its using >>>>>> ntpdate >>>>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>>>>> >>>>>> I've noticed if ntpd is already running on the client when you run > the >>>>>> ipa-client-install, you will get that error. I'm guessing its using >>>>>> ntpdate >>>>>> IP ADDRESS to sync time, and cannot do so when the daemon is running. >>>>>> >>>>> Now that you mentioned that I would agree with you in that it > is >>>>> failing because ntpd is running already; I could not see it because of >>>>> the option "-s" in >>>>> >>>>> [root at centos64 ~]# service ntpd status >>>>> ntpd (pid 3721) is running... >>>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v > auth.in.domain.com >>>>> [root at centos64 ~]# >>>>> >>>>> I could not find what all of those arguments mean in the centos 6.5 >>>>> ntpdate man page, but here is what I found under ubuntu's: >>>>> >>>>> -b Force the time to be stepped using the > settimeofday() >>>>> system >>>>> call, rather than slewed (default) using the > adjtime() >>>>> system >>>>> call. This option should be used when called from a > startup >>>>> file >>>>> at boot time. >>>>> >>>>> -s Divert logging output from the standard output > (default) to >>>>> the >>>>> system syslog facility. This is designed primarily > for >>>>> conve? >>>>> nience of cron scripts. >>>>> >>>>> -v Be verbose. This option will cause ntpdate's version >>>>> identifica? >>>>> tion string to be logged. >>>>> >>>>> In other words, -s is sending the output to syslog. And, if we check >>>>> /var/log/messages we will find that >>>>> >>>>> Feb 9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, > exiting >>>>> >>>>> as you expected. Now, how did it detect the ntpdate failed? >>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares >>>>>> wrote: >>>>>>> >>>>>>> Even though I already have a ntp server, I setup my newly >>>>>>> created freeipa kdc to do that too (it is a slave to my primary > ntp). >>>>>>> >>>>>>> I then build a centos host to be the test client. Just to make sure > it >>>>>>> can see and use auth's ntp, I tested with ntpdate: >>>>>>> >>>>>>> [root at centos64 ~]# ntpdate auth >>>>>>> 8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset >>>>>>> -0.003097 sec >>>>>>> [root at centos64 ~]# >>>>>>> >>>>>>> so far so good, so how about running ipa-client-install? >>>>>>> >>>>>>> [root at centos64 ~]# hostname >>>>>>> centos64 >>>>>>> [root at centos64 ~]# ipa-client-install --hostname=`hostname -f` >>>>>>> Discovery was successful! >>>>>>> Hostname: centos64.in.domain.com >>>>>>> Realm: DOMAIN.COM >>>>>>> DNS Domain: domain.com >>>>>>> IPA Server: auth.in.domain.com >>>>>>> BaseDN: dc=domain,dc=com >>>>>>> >>>>>>> [so far so good!] >>>>>>> >>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>> User authorized to enroll computers: admin >>>>>>> Synchronizing time with KDC... >>>>>>> Unable to sync time with IPA NTP server, assuming the time is in > sync. >>>>>>> Please check that 123 UDP port is opened. >>>>>>> Password for admin at DOMAIN.COM: >>>>>>> >>>>>>> But, it had not problems using ntpdate against auth. to add insult > to >>>>>>> injury, the log claims it is using ntpdate: >>>>>>> >>>>>>> 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v >>>>>>> auth.in.domain.com >>>>>>> 2014-02-08T13:14:31Z DEBUG stdout= >>>>>>> 2014-02-08T13:14:31Z DEBUG stderr= >>>>>>> 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP > server, >>>>>>> assuming the time is in sync. Please check that 123 UDP port is >>>>>>> opened. >>>>>>> >>>>>>> Could it be it is pissed because it was in sync to begin with? I > mean, >>>>>>> if we run the exact command the log file claims to have run, >>>>>>> >>>>>>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v > auth.in.domain.com| >>>>>>> echo $? >>>>>>> 0 >>>>>>> [root at centos64 ~]# >>>>>>> >>>>>>> We see it was successful. >>>>>>> >>>>>>> I am feeling rather clueless here... >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> This sounds like a bug to me but I would wait for European gurus to > chime in >>>> the morning. >>>> If it is a bug we need a ticket. >>>> >>> I dunno where to file a ticket but here is my suggestion: >>> >>> in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def >>> synconce_ntp(server_fqdn): >>> >>> replace >>> >>> cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn] >>> >>> with >>> >>> cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", > server_fqdn] >>> >>> Reasoning: >>> >>> [root at centos64 ~]# date +%T -s "10:13:13" >>> 10:13:13 >>> [root at centos64 ~]# date >>> Mon Feb 10 10:13:15 EST 2014 >>> [root at centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u auth >>> [root at centos64 ~]# date >>> Mon Feb 10 16:05:49 EST 2014 >>> [root at centos64 ~]# service ntpd status >>> ntpd (pid 8870) is running... >>> [root at centos64 ~]# >> >> Just to close the loop - this is the filed Bugzilla: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1063512 >> >> I will clone it upstream so that we can triage it. > > Sorry. I didn't know I could submit a patch and how. It's already > impressive I did the bugzilla thing. I can also do the patch, but would it > then be redundant? Bugzilla is just a bug tracker - it allows us to organize development and to know what we need to fix/add etc. If you send a patch we will handle the paperwork for you (I mean closing the bug etc.) :-) If you want to send a patch, please follow instructions on page: http://www.freeipa.org/page/Contribute/Code#Get_the_source Don't hesitate to ask any question. Thank you for your time. Have a nice day! -- Petr^2 Spacek From rcritten at redhat.com Tue Feb 11 15:32:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Feb 2014 10:32:45 -0500 Subject: [Freeipa-users] Upgrade of Free ipa in CENTOS 6 In-Reply-To: References: Message-ID: <52FA429D.8000705@redhat.com> barrykfl at gmail.com wrote: > Dear all: > Any one have exp to upgrade ipa-server-3.0.0-26.el6_4.4.x86_64 to > ipa-server-3.0.0-37.el6_4.4.x86_64 ( jus t minor patch/upgrade it think ) > Is it just yum install then ok ??? i notice some official document but > they are 3.3 free ipa of fedora ...just yum / run the rpm and not > necessary shut down. Yes, yum update should be enough. > Is it same in CENTOS ipa 3.0 server one ? > http://www.freeipa.org/page/Releases/3.2.0#Upgrading This applied only to Fedora and related to switching major versions of the CA. This doesn't apply to RHEL and clones. rob From rcritten at redhat.com Tue Feb 11 15:57:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Feb 2014 10:57:05 -0500 Subject: [Freeipa-users] export user info In-Reply-To: <52F8BA8D.5030103@redhat.com> References: <52F8BA8D.5030103@redhat.com> Message-ID: <52FA4851.9010203@redhat.com> Martin Kosek wrote: > On 02/10/2014 12:01 PM, barrykfl at gmail.com wrote: >> Dear all: >> >> Which command can export /show all users a/c and info? better in table >> format . >> >> Regards >> >> Barry > > $ ipa user-find > > Or in JSON-RPC command: > > {"method":"user_find","params":[[""],{"sizelimit":0}]} > Be aware that the LDAP server applies its own limits to user queries which by default is IIRC 2k. So if you have more than 2k users you'll need to also modify the LDAP global limits. rob From djablonski at gatessolutions.com Tue Feb 11 16:22:23 2014 From: djablonski at gatessolutions.com (Dave Jablonski) Date: Tue, 11 Feb 2014 10:22:23 -0600 Subject: [Freeipa-users] CentOS 6.5 client install failing In-Reply-To: <52FA47CB.609@redhat.com> References: <52F635A5.3040609@redhat.com> <52FA47CB.609@redhat.com> Message-ID: The last line in the log should be: 2014-02-06T16:27:48Z DEBUG Caught fault 1101 from server https://mgmt-001.domain/ipa/xml: did not receive Kerberos credentials The python modules import happened after I tried to re-install again. Sorry for the confusion. ipa-client-3.0.0-37.el6.x86_64 On Tue, Feb 11, 2014 at 9:54 AM, Rob Crittenden wrote: > Dave Jablonski wrote: > >> I've attached the whole client log. Thank you. >> > > Not sure if it is related to the failure or not but the log seems cut off > at the end. Can you double-check it, it ends with a bunch of python imports. > > Also, what is the output of rpm -q ipa-client ? > > I see the fallback code in 3.0.0-37 but it doesn't seem to be executing > here. > > rob > > >> >> On Sat, Feb 8, 2014 at 7:48 AM, Rob Crittenden > > wrote: >> >> Dave Jablonski wrote: >> >> FreeIPA Server: Fedora 16, freeipa 2.1.4 >> Latest CentOS 6.5 client >> >> When running: >> >> ipa-client-install --mkhomedir --enable-dns-updates >> >> The install fails with: >> >> trying https:///ipa/xml >> Forwarding 'env' to server u'https:///ipa/__xml' >> >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install"__, line 2377, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install"__, line 2363, in main >> >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install"__, line 2167, in install >> remote_env = api.Command['env'](server=__True)['result'] >> File >> "/usr/lib/python2.6/site-__packages/ipalib/frontend.py", line >> 435, >> >> in __call__ >> ret = self.run(*args, **options) >> File >> "/usr/lib/python2.6/site-__packages/ipalib/frontend.py", line >> >> 1073, in run >> return self.forward(*args, **options) >> File >> "/usr/lib/python2.6/site-__packages/ipalib/frontend.py", line >> 769, >> in forward >> return self.Backend.xmlclient.__forward(self.name >> , >> >> *args, **kw) >> File "/usr/lib/python2.6/site-__packages/ipalib/rpc.py", >> >> line 736, in >> forward >> raise error(message=e.faultString) >> ipalib.errors.CCacheError: did not receive Kerberos credentials >> >> In /var/log/ipaclient-install.__log: >> >> >> 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer >> intended_usage = >> SSLServer >> 2014-02-06T18:19:53Z DEBUG cert valid True for >> "CN=,O=" >> 2014-02-06T18:19:53Z DEBUG handshake complete, peer = >> 10.1.1.111:443 >> >> >> 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server >> https:///ipa/xml: did not receive Kerberos >> credentials >> >> >> We need to see more context from the client install log, preferably >> the whole thing. >> >> IPA v2 doesn't support session cookies but the 3.x client should >> have support for falling back to using TGT delegation. >> >> rob >> >> >> >> >> -- >> David Jablonski >> Performance Gateway >> Email: _djablonski at p >> erformancegateway.com >> _ >> _ >> >> _ >> >> IMPORTANT: This e-mail (including any attachments) is intended for the >> use of the individual or entity to which it is addressed and may contain >> information that is classified, private, or confidential. If the reader >> of this message is not the intended recipient, or the employee or agent >> responsible for delivering the message to the intended recipient, you >> are hereby notified that any dissemination, distribution, or copying of >> this communication is prohibited. If you have received this >> communication in error, please notify us immediately by replying to this >> e-mail. Thank you. >> >> >> IMPORTANT: This e-mail (including any attachments) is intended for the >> use of the individual or entity to which it is addressed and may contain >> information that is classified, private, or confidential. If the reader >> of this message is not the intended recipient, or the employee or agent >> responsible for delivering the message to the intended recipient, you >> are hereby notified that any dissemination, distribution, or copying of >> this communication is prohibited. If you have received this >> communication in error, please notify us immediately by replying to this >> e-mail. Thank you. >> >> > -- David Jablonski Performance Gateway Email: *djablonski at p erformancegateway.com * IMPORTANT: This e-mail (including any attachments) is intended for the use of the individual or entity to which it is addressed and may contain information that is classified, private, or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. Thank you. -- IMPORTANT: This e-mail (including any attachments) is intended for the use of the individual or entity to which it is addressed and may contain information that is classified, private, or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to this e-mail. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Tue Feb 11 17:02:19 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Tue, 11 Feb 2014 09:02:19 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <20140208092932.GA11564@mail.corp.redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> Message-ID: <1392138139.7497.YahooMailNeo@web160103.mail.bf1.yahoo.com> Lukas I read the information on those two links, my problem is different. My replica is working fine, the database has all the records. My problem is I am not able to use the replica for ipa-client -install. In one of my replies I sent information that kinit was trying to access my master instead of the replica. Let me know what you think. Thanks ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik wrote: On (06/02/14 18:33), Shree wrote: >First of all, the?ipa-replica-install did not allow me to use the?--setup-ca > option complaining that a cert already exists, replicate creation was > successful after I skipped the option. >Seems like the replica is one except? >1) There is no CA Service running on the replica (which I guess is expected) >and >2) I am unable to run?ipa-client-install successfully on any clients using > the replica. (I don't have the option of using the primary master as it is > configured in a segregated environment. Only the master and replica are > allowed to sync. >Debug shows it fails at? > >ipa ? ? ? ? : DEBUG ? ?stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com'?while getting initial credentials > > I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Tue Feb 11 17:55:27 2014 From: sdainard at miovision.com (Steve Dainard) Date: Tue, 11 Feb 2014 12:55:27 -0500 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts In-Reply-To: References: <20140210160900.GA2635@localhost.localdomain> Message-ID: I added a Ubuntu 13.10 client (after some trial and error) and after the first login it takes less than 2 seconds to authenticate. I must say its absolutely brilliant to have the client auth to Windows domain shares without prompts :) I've attached the clients sssd log for reference, hopefully it helps. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_miolinux.corp.log.ubu1310 Type: application/octet-stream Size: 1530338 bytes Desc: not available URL: From tsoucy at salesforce.com Tue Feb 11 18:00:56 2014 From: tsoucy at salesforce.com (Terry Soucy) Date: Tue, 11 Feb 2014 14:00:56 -0400 Subject: [Freeipa-users] Unable to access systems Message-ID: We are transitioning from one IPA instance to a new IPA instance. The version of IPA instances is the same, and all is functioning normally on the existing IPA, but when I attempt to transition a host to the new IPA instance, I get the following in my logs when I attempt an SSH .. [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to 'all'. [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to 'all'. [sssd[be[dev.ca1.sfmc.co]]] [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to 'all'. [sssd[be[dev.ca1.sfmc.co]]] [hbac_host_attrs_to_rule] (4): No host specified, rule will never apply. [sssd[be[dev.ca1.sfmc.co]]] [ipa_hbac_evaluate_rules] (3): Access denied by HBAC rules [sssd[be[dev.ca1.sfmc.co]]] [be_pam_handler_callback] (4): Backend returned: (0, 6, ) [Success] The HBAC rule, according to the test, will grant me access since I'm in the appropriate group Rule name: hbac_techops Host category: all Service category: all Description: TechOps Access Enabled: TRUE User Groups: ug-techops I'm not sure what "No host specified, rule will never apply" means. I attempted to add the host to the rule rather than use a hostgroup, but the result is the same Server - RH 6.4, ipa-server-3.0.0-37.el6.x86_64 Client - Ubuntu 10, sssd 1.5.15-0ubuntu6~lucid2 sssd.conf [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = dev.ca1.sfmc.co [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/dev.ca1.sfmc.co] debug_level = 5 enumerate = true cache_credentials = true id_provider = ipa auth_provider = ipa chpass_provider = ipa access_provider = ipa krb5_store_password_if_offline = True ipa_server = _srv_ ldap_tls_cacert = /etc/ipa/ca.crt krb5_realm = SFMC.CO krb5_changepw_principle = kadmin/changepw krb5_auth_timeout = 15 ipa_hostname = vm3118.dev.ca1.sfmc.co -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Tue Feb 11 18:29:43 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Tue, 11 Feb 2014 20:29:43 +0200 Subject: [Freeipa-users] Choosing the right way to create trust Message-ID: I work in environment where the AD is the DC of the windows machines , while the linux machines (RHEL 5\6) are not centrally managed. I would like to create an IPA server to manage the linux machines while creating a trust with AD. The current situation is all windows and linux machines are under .zone.corp domain. >From what ive read at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html, i can create trust when IPA is a subdomain of AD domain or when the domains are separate. I'm not sure what is the method i should approach. Can IPA be a dc inside the AD domain? Or should i create a subdomain for linux and then move all the linux machines to the new domain (I hope not). Any advice? -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at tdiehl.org Tue Feb 11 18:56:01 2014 From: me at tdiehl.org (me at tdiehl.org) Date: Tue, 11 Feb 2014 13:56:01 -0500 (EST) Subject: [Freeipa-users] Are multiple dns databases possible in freeipa? Message-ID: Hi, I am in the process of evaluating ipa on Centos 6.5. So far I really like what I see but the one problem I cannot find a viable solution for is how can I do internal and external views with dns stored in ipa? Google seems to indicate that it is not possible but I thought I would ask here to be sure. My dns infrastructure serves different ip addresses depending on if the request originates from the internal network or from the Internet. In addition, internal hosts are able to do recursive look ups but for external hosts recursion is not allowed. I am thinking that if I can add a second dns database to ipa, I could then configure named.conf to operate using views. Is this possible/recommended? Is there a better solution that would not be a maintenance nightmare? Regards, -- Tom me at tdiehl.org Spamtrap address me123 at tdiehl.org From jokajak at gmail.com Tue Feb 11 19:00:55 2014 From: jokajak at gmail.com (Josh) Date: Tue, 11 Feb 2014 14:00:55 -0500 Subject: [Freeipa-users] SELinux user categories Message-ID: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> I have a situation where I need to support more than 1024 categories on a system. I modified the selinuxusermap.py file to check for the number of categories I need but ipa still responds with the original error message. Do I need to restart any of the services? Here is the command that was run and the output after applying the patch below: ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] Thanks, -josh PS: This is the patch that was applied --- /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py.cats 2014-02-11 13:18:19.868574971 -0500 +++ /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py 2014-02-11 13:20:03.563127380 -0500 @@ -99,9 +99,9 @@ def validate_selinuxuser(ugettext, user) if not mls or not regex_mls.match(mls): return _('Invalid MLS value, must match s[0-15](-s[0-15])') m = regex_mcs.match(mcs) - if mcs and (not m or (m.group(3) and (int(m.group(3)) > 1023))): - return _('Invalid MCS value, must match c[0-1023].c[0-1023] ' - 'and/or c[0-1023]-c[0-c0123]') + if mcs and (not m or (m.group(3) and (int(m.group(3)) > 16384))): + return _('Invalid MCS value, must match c[0-16384].c[0-16384] ' + 'and/or c[0-16384]-c[0-16384]') return None From rcritten at redhat.com Tue Feb 11 19:44:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Feb 2014 14:44:55 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> Message-ID: <52FA7DB7.3070402@redhat.com> Josh wrote: > I have a situation where I need to support more than 1024 categories on a system. I modified the selinuxusermap.py file to check for the number of categories I need but ipa still responds with the original error message. Do I need to restart any of the services? > > Here is the command that was run and the output after applying the patch below: > > ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' > ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] Have you updated your SELinux policy to support a larger MCS range? If not then this will get you past the IPA validator but it won't work with SELinux. See semanage(8). rob > > Thanks, > -josh > > PS: This is the patch that was applied > > --- /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py.cats 2014-02-11 13:18:19.868574971 -0500 > +++ /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py 2014-02-11 13:20:03.563127380 -0500 > @@ -99,9 +99,9 @@ def validate_selinuxuser(ugettext, user) > if not mls or not regex_mls.match(mls): > return _('Invalid MLS value, must match s[0-15](-s[0-15])') > m = regex_mcs.match(mcs) > - if mcs and (not m or (m.group(3) and (int(m.group(3)) > 1023))): > - return _('Invalid MCS value, must match c[0-1023].c[0-1023] ' > - 'and/or c[0-1023]-c[0-c0123]') > + if mcs and (not m or (m.group(3) and (int(m.group(3)) > 16384))): > + return _('Invalid MCS value, must match c[0-16384].c[0-16384] ' > + 'and/or c[0-16384]-c[0-16384]') > return None > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Tue Feb 11 19:47:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Feb 2014 14:47:52 -0500 Subject: [Freeipa-users] Are multiple dns databases possible in freeipa? In-Reply-To: References: Message-ID: <52FA7E68.2070006@redhat.com> me at tdiehl.org wrote: > Hi, > > I am in the process of evaluating ipa on Centos 6.5. So far I really > like what > I see but the one problem I cannot find a viable solution for is how can > I do > internal and external views with dns stored in ipa? Google seems to > indicate > that it is not possible but I thought I would ask here to be sure. > > My dns infrastructure serves different ip addresses depending on if the > request originates from the internal network or from the Internet. > > In addition, internal hosts are able to do recursive look ups but for > external > hosts recursion is not allowed. > > I am thinking that if I can add a second dns database to ipa, I could then > configure named.conf to operate using views. > > Is this possible/recommended? Is there a better solution that would not be > a maintenance nightmare? > > Regards, > Bind views are not currently supported, see this thread http://www.redhat.com/archives/freeipa-users/2013-October/msg00005.html There is an upstream ticket on this as well, https://fedorahosted.org/freeipa/ticket/2802 rob From rcritten at redhat.com Tue Feb 11 19:52:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Feb 2014 14:52:35 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> Message-ID: <52FA7F83.1070709@redhat.com> Josh wrote: > > On Feb 11, 2014, at 2:44 PM, Rob Crittenden > wrote: > >> Josh wrote: >>> I have a situation where I need to support more than 1024 categories >>> on a system. I modified the selinuxusermap.py file to check for the >>> number of categories I need but ipa still responds with the original >>> error message. Do I need to restart any of the services? >>> >>> Here is the command that was run and the output after applying the >>> patch below: >>> >>> ipa config-mod >>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >> >> Have you updated your SELinux policy to support a larger MCS range? If >> not then this will get you past the IPA validator but it won't work >> with SELinux. See semanage(8). >> >> rob > > Yes. I?m trying to set the SELinux categories in freeipa because when > you have lots of categories all semanage commands slow down (way down). > For other people?s knowledge, this requires recompilation of the > SELinux policy. Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. regards rob > > -josh > >> >>> >>> Thanks, >>> -josh >>> >>> PS: This is the patch that was applied >>> >>> --- >>> /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py.cats 2014-02-11 >>> 13:18:19.868574971 -0500 >>> +++ /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py >>> 2014-02-11 13:20:03.563127380 -0500 >>> @@ -99,9 +99,9 @@ def validate_selinuxuser(ugettext, user) >>> if not mls or not regex_mls.match(mls): >>> return _('Invalid MLS value, must match s[0-15](-s[0-15])') >>> m = regex_mcs.match(mcs) >>> - if mcs and (not m or (m.group(3) and (int(m.group(3)) > 1023))): >>> - return _('Invalid MCS value, must match c[0-1023].c[0-1023] ' >>> - 'and/or c[0-1023]-c[0-c0123]') >>> + if mcs and (not m or (m.group(3) and (int(m.group(3)) > 16384))): >>> + return _('Invalid MCS value, must match c[0-16384].c[0-16384] ' >>> + 'and/or c[0-16384]-c[0-16384]') >>> return None >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > From maleko42 at gmail.com Tue Feb 11 21:22:23 2014 From: maleko42 at gmail.com (Mark Gardner) Date: Tue, 11 Feb 2014 16:22:23 -0500 Subject: [Freeipa-users] Recommend version of Samba for a CentOS 6.5 IPA client? Message-ID: Before I go installing Samba for File Sharing. I wanted to make sure I was installing the correct version of Samba without conflicting with the Linux server being an IPA client. Currently installed sambaX packages: samba-client.x86_64 3.6.9-167.el6_5 @updates samba-common.x86_64 3.6.9-167.el6_5 @updates samba-winbind.x86_64 3.6.9-167.el6_5 @updates samba-winbind-clients.x86_64 3.6.9-167.el6_5 @updates samba4-libs.x86_64 4.0.0-60.el6_5.rc4 @updates So do I uninstall samba 3.6.9 and install the appropriate samba4 packages or just yum install samba? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Tue Feb 11 22:02:14 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Tue, 11 Feb 2014 22:02:14 +0000 Subject: [Freeipa-users] trouble creating a replica in the cloud Message-ID: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> Hey Guys, So I have my master and replica up in my datacenter. I have a client, I have a winsync agreement, I have a password sync. It's working lovely. So Now I have spun up an AWS instance of redh hat 6.5 (same as my master and first replica) I run the ipa replica and it fails ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-se-idm-03.boingo.com.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'se-idm-01.boingo.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 PKI-CA: Directory Service port (7389): 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 BOINGO.COM password: Execute check on remote master Check connection from master to remote replica 'se-idm-03.boingo.com': 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 PKI-CA: Directory Service port (7389): OK Connection from master to replica is OK. Connection check OK 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 for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance ipa : CRITICAL failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3' returned non-zero exit status 1 [3/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. Done configuring directory server for the CA (pkids). Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Can't contact LDAP server I check the log file and this is what I get 2014-02-11T19:55:48Z DEBUG calling setup-ds.pl 2014-02-11T19:57:53Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3 2014-02-11T19:57:53Z DEBUG stdout=[11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: Netscape Portable Runtime error -5966 (Access Denied.) [11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: Netscape Portable Runtime error -5966 (Access Denied.) [14/02/11:14:57:53] - [Setup] Info Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[11/Feb/2014:14:57:53 -0500] create prlistensockets - PR_Bind() on All Interfaces port 7389 failed: Netscape Portable Runtime error -5966 (Access Denied.) '. Error: Unknown error 256 Could not start the directory server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the error log was '[11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: Netscape Portable Runtime error -5966 (Access Denied.) '. Error: Unknown error 256 [14/02/11:14:57:53] - [Setup] Fatal Error: Could not create directory server instance 'PKI-IPA'. Error: Could not create directory server instance 'PKI-IPA'. [14/02/11:14:57:53] - [Setup] Fatal Exiting . . . Log file is '-' Exiting . . . Log file is '-' Please help -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Tue Feb 11 22:53:46 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Tue, 11 Feb 2014 14:53:46 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FAA2B1.3090506@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> Message-ID: <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> Following ports are opened between the? 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional).? When the replica was up it worked fine as far as syncing was concerned.? ?80 tcp ?443 tcp ?389 tcp ?636 tcp ?88 tcp ?464 tcp ?88 udp ?464 udp ?123 udp ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri >Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not reply to me directly. Did you set your first server with the CA? Does all ports that need to be open in the firewall between primary or server are actually open? > >What I have done so far is uninstalled the replica and tried to install it again using the "--setup-ca" option. Previously I had failures and when I removed the "--setup-ca" option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. > > >1)The workaround helped me go forward a bit but I got stuck at this point see below >=========== >? [1/3]: creating directory server user >? [2/3]: creating directory server instance >? [3/3]: restarting directory server >Done configuring directory server for the CA (pkids). >ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >? [1/17]: creating certificate server user >? [2/17]: creating pki-ca instance >? [3/17]: configuring certificate server instance >ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >=========== >2) No we do not use IPA for a DNS server. > > >3)The reason for this could be that I had installed the replica without the "--setup-ca". >? >Shreeraj >---------------------------------------------------------------------------------------- > > > >Change is the only Constant ! > > > >On Monday, February 10, 2014 12:43 PM, Dmitri Pal wrote: > >On 02/09/2014 07:44 AM, Rob Crittenden wrote: >> Shree wrote: >>> Lukas >>> Perhaps I should explain the design a bit and see if FreeIPA even >>> supports this.Our replica is in a separate network and all the >>> appropriate ports are opened between the master and the replica. The >>> "replica" got created successfully and is in sync with the master >>> (except the CA services which I mentioned earlier) >>> Now,when I try to run ipa-client-install on hosts in the new network >>> using the replica, it complains that about "Cannot contact any KDC for >>> realm". >>> I am wondering it my hosts in the new network are trying to access the >>> "master" for certificates since the replica does not have any CA >>> services running? I couldn't find any obvious proof of this even running >>> the install in a debug mode. Do I need to open ports between the new >>> hosts and the master for CA services? >>> At this point I cannot disable or? move the master, it needs to function >>> in its location but I need >> >> No, the clients don't directly talk to the CA. >> >> You'd need to look in /var/log/ipaclient-install.log to see what KDC >> was found and we were trying to use. If you have SRV records for both >> but we try to contact the hidden master this will happen. You can try >> specifying the server on the command-line with --server but this will >> be hardcoding things and make it less flexible later. >> >> rob >> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik >>> wrote: >>> On (06/02/14 18:33), Shree wrote: >>> >>> >First of all, the ipa-replica-install did not allow me to use >>> the --setup-ca >>> > option complaining that a cert already exists, replicate creation was >>> > successful after I skipped the option. >>> >Seems like the replica is one except >>> >1) There is no CA Service running on the replica (which I guess is >>> expected) >>> >and >>> >2) I am unable to run ipa-client-install successfully on any clients >>> using >>> > the replica. (I don't have the option of using the primary master as >>> it is >>> > configured in a segregated environment. Only the master and replica >>> are >>> > allowed to sync. >>> >Debug shows it fails at >>> > >>> >ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot contact any KDC for realm >>> 'mydomainname.com' while getting initial credentials >>> >>> > >>> > >>> >>> I was not able to install replica witch CA on fedora 20, >>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>> >>> Guys from dogtag found a workaround >>> https://fedorahosted.org/pki/ticket/816#comment:12 >>> >>> Does it work for you? >>> >>> LS >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > >What server provides DNS capabilities to the clients? >Do you use IPA DNS or some other DNS? >Clients seem to not be able to see replica KDC and try to access hidden >master but they can know about this master only via DNS. > > >-- >Thank you, >Dmitri Pal > >Sr. Engineering Manager for IdM portfolio >Red Hat Inc. > > >------------------------------- >Looking to carve out IT costs? >www.redhat.com/carveoutcosts/ > > > > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Wed Feb 12 03:55:51 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 12 Feb 2014 11:55:51 +0800 Subject: [Freeipa-users] By default on port 389 , any encryption between client and server Message-ID: Hi all: Some doc said it already build in TLS on 389 ... is it nsslapd-minssf on the dse.ldif? Should i need to set 636 ldaps ? or set higher nsslapd-minssf enough? What document tell the default secure connection of free ipa? thks barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Feb 12 08:45:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Feb 2014 09:45:15 +0100 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <52FB349B.6020901@redhat.com> On 11.2.2014 23:53, Shree wrote: > Following ports are opened between the > 1) Between the master and the replica (bi directional) > 2) client machine and the ipa replica (unidirectional). > When the replica was up it worked fine as far as syncing was concerned. > > 80 tcp > 443 tcp > 389 tcp > 636 tcp > 88 tcp > 464 tcp > 88 udp > 464 udp > 123 udp > > Shreeraj > ---------------------------------------------------------------------------------------- > > Change is the only Constant ! > > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal wrote: > > On 02/11/2014 05:05 PM, Shree wrote: > Dimitri >> Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) > Please republish it on the list. > Do not reply to me directly. > > Did you set your first server with the CA? Does all ports that need > to be open in the firewall between primary or server are actually > open? > > > >> >> What I have done so far is uninstalled the replica and tried to install it again using the "--setup-ca" option. Previously I had failures and when I removed the "--setup-ca" option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. >> >> >> 1)The workaround helped me go forward a bit but I got stuck at this point see below >> =========== >> [1/3]: creating directory server user >> [2/3]: creating directory server instance >> [3/3]: restarting directory server >> Done configuring directory server for the CA (pkids). >> ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >> [1/17]: creating certificate server user >> [2/17]: creating pki-ca instance >> [3/17]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >> =========== >> 2) No we do not use IPA for a DNS server. >> >> >> 3)The reason for this could be that I had installed the replica without the "--setup-ca". >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> >> Change is the only Constant ! >> >> >> >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal wrote: >> >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>> Shree wrote: >>>> Lukas >>>> Perhaps I should explain the design a bit and > see if FreeIPA even >>>> supports this.Our replica is in a separate > network and all the >>>> appropriate ports are opened between the master > and the replica. The >>>> "replica" got created successfully and is in > sync with the master >>>> (except the CA services which I mentioned > earlier) >>>> Now,when I try to run ipa-client-install on > hosts in the new network >>>> using the replica, it complains that about > "Cannot contact any KDC for >>>> realm". >>>> I am wondering it my hosts in the new network > are trying to access the >>>> "master" for certificates since the replica > does not have any CA >>>> services running? I couldn't find any obvious > proof of this even running >>>> the install in a debug mode. Do I need to open > ports between the new >>>> hosts and the master for CA services? >>>> At this point I cannot disable or move the > master, it needs to function >>>> in its location but I need >>> >>> No, the clients don't directly talk to the CA. >>> >>> You'd need to look in > /var/log/ipaclient-install.log to see what KDC >>> was found and we were trying to use. If you have > SRV records for both >>> but we try to contact the hidden master this will > happen. You can try >>> specifying the server on the command-line with > --server but this will >>> be hardcoding things and make it less flexible > later. >>> >>> rob >>> >>>> Shreeraj >>>> > ---------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> Change is the only Constant ! >>>> >>>> >>>> On Saturday, February 8, 2014 1:29 AM, Lukas > Slebodnik >>>> wrote: >>>> On (06/02/14 18:33), Shree wrote: >>>> >>>>> First of all, the ipa-replica-install did > not allow me to use >>>> the --setup-ca >>>>> option complaining that a cert already > exists, replicate creation was >>>>> successful after I skipped the option. >>>>> Seems like the replica is one except >>>>> 1) There is no CA Service running on the > replica (which I guess is >>>> expected) >>>>> and >>>>> 2) I am unable to run ipa-client-install > successfully on any clients >>>> using >>>>> the replica. (I don't have the option of > using the primary master as >>>> it is >>>>> configured in a segregated environment. > Only the master and replica >>>> are >>>>> allowed to sync. >>>>> Debug shows it fails at >>>>> >>>>> ipa : DEBUG stderr=kinit: Cannot > contact any KDC for realm >>>> 'mydomainname.com' while getting initial > credentials >>>> >>>>> >>>>> >>>> >>>> I was not able to install replica witch CA on > fedora 20, >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>> >>>> Guys from dogtag found a workaround >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>> >>>> Does it work for you? >>>> >>>> LS >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> What server provides DNS capabilities to the clients? >> Do you use IPA DNS or some other DNS? >> Clients seem to not be able to see replica KDC and try > to access hidden >> master but they can know about this master only via DNS. Shree, make sure that command $ dig -t SRV _kerberos._udp.ipa.example on the client returns both IPA servers (in ANSWER section). -- Petr^2 Spacek From sbose at redhat.com Wed Feb 12 08:45:47 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 12 Feb 2014 09:45:47 +0100 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: References: Message-ID: <20140212084547.GC19631@localhost.localdomain> On Tue, Feb 11, 2014 at 08:29:43PM +0200, Genadi Postrilko wrote: > I work in environment where the AD is the DC of the windows machines , > while the linux machines (RHEL 5\6) are not centrally managed. > I would like to create an IPA server to manage the linux machines while > creating a trust with AD. > The current situation is all windows and linux machines are under > .zone.corp domain. > >From what ive read at > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html, > i can create trust when IPA is a subdomain of AD domain or when the > domains are separate. I'm not sure what is the method i should approach. > Can IPA be a dc inside the AD domain? Or should i create a subdomain for > linux and then move all the linux machines to the new domain (I hope not). I'm afraid you have to move the linux machines to a separate domain when you want to use trust. The reason is that Kerberos heavily depends DNS and e.g use the fully qualified host names and DNS SRV records to determine memberships to realm and KDCs in a realm. HTH bye, Sumit > > Any advice? > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Wed Feb 12 08:49:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 09:49:00 +0100 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: References: Message-ID: <52FB357C.8080307@redhat.com> On 02/11/2014 07:29 PM, Genadi Postrilko wrote: > I work in environment where the AD is the DC of the windows machines , > while the linux machines (RHEL 5\6) are not centrally managed. > I would like to create an IPA server to manage the linux machines while > creating a trust with AD. > The current situation is all windows and linux machines are under > .zone.corp domain. >>From what ive read at > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html, > i can create trust when IPA is a subdomain of AD domain or when the > domains are separate. I'm not sure what is the method i should approach. > Can IPA be a dc inside the AD domain? Or should i create a subdomain for > linux and then move all the linux machines to the new domain (I hope not). > > Any advice? The key here is that for IPA and AD to be able to work together in a trust, they need to be in separate domains with realm matching this domains. In your case, it seems to me that a following scenario would work the best: * AD with domain zone.corp and realm ZONE.CORP * IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated from the AD DNS (or other DNS you use). More info here: http://www.freeipa.org/page/Trusts Martin From pspacek at redhat.com Wed Feb 12 08:53:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Feb 2014 09:53:27 +0100 Subject: [Freeipa-users] Are multiple dns databases possible in freeipa? In-Reply-To: <52FA7E68.2070006@redhat.com> References: <52FA7E68.2070006@redhat.com> Message-ID: <52FB3687.2060804@redhat.com> On 11.2.2014 20:47, Rob Crittenden wrote: > me at tdiehl.org wrote: >> Hi, >> >> I am in the process of evaluating ipa on Centos 6.5. So far I really >> like what >> I see but the one problem I cannot find a viable solution for is how can >> I do >> internal and external views with dns stored in ipa? Google seems to >> indicate >> that it is not possible but I thought I would ask here to be sure. >> >> My dns infrastructure serves different ip addresses depending on if the >> request originates from the internal network or from the Internet. >> >> In addition, internal hosts are able to do recursive look ups but for >> external >> hosts recursion is not allowed. >> >> I am thinking that if I can add a second dns database to ipa, I could then >> configure named.conf to operate using views. >> >> Is this possible/recommended? Is there a better solution that would not be >> a maintenance nightmare? >> >> Regards, >> > > Bind views are not currently supported, see this thread > http://www.redhat.com/archives/freeipa-users/2013-October/msg00005.html > > There is an upstream ticket on this as well, > https://fedorahosted.org/freeipa/ticket/2802 Hello Tom, we can provide you configuration file for BIND 9 which allows you to load data for external view from a file and use LDAP (with FreeIPA CLI and WebUI) for internal view (or vice versa). Let me know if you are interested in this configuration. Could you describe your use case in detail? What are you trying to achieve, why etc.? We need to know use cases so we can design proper solution. Would "sites" be enough for you? See https://fedorahosted.org/freeipa/ticket/2008 Thank you for your time! -- Petr^2 Spacek From mkosek at redhat.com Wed Feb 12 09:02:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Feb 2014 10:02:09 +0100 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <52FA7F83.1070709@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> Message-ID: <52FB3891.3070908@redhat.com> On 02/11/2014 08:52 PM, Rob Crittenden wrote: > Josh wrote: >> >> On Feb 11, 2014, at 2:44 PM, Rob Crittenden > > wrote: >> >>> Josh wrote: >>>> I have a situation where I need to support more than 1024 categories >>>> on a system. I modified the selinuxusermap.py file to check for the >>>> number of categories I need but ipa still responds with the original >>>> error message. Do I need to restart any of the services? >>>> >>>> Here is the command that was run and the output after applying the >>>> patch below: >>>> >>>> ipa config-mod >>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>> >>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>> >>> Have you updated your SELinux policy to support a larger MCS range? If >>> not then this will get you past the IPA validator but it won't work >>> with SELinux. See semanage(8). >>> >>> rob >> >> Yes. I?m trying to set the SELinux categories in freeipa because when >> you have lots of categories all semanage commands slow down (way down). >> For other people?s knowledge, this requires recompilation of the >> SELinux policy. > > Ok, then your patch looks reasonable. The current code is for the default > values and we haven't had cause to make this configurable before now. You might > consider filing a ticket in our trac about this. > > Also note that this change will be lost on your next IPA upgrade, and you'll > need to make this change on any IPA master you want these values to be managed. > The data will remain unchanged, but the original python values will be restored > if you update the packages. > > I don't believe validators are currently extensible in the IPA framework. That > might be something we need to look at as well. > > regards > > rob I am thinking you may be able to monkeypatch the validator in a custom plugin, like selinuxusermap-user.py which would: ~~~~ import ipalib.plugins.selinuxusermap( def custom_selinux_usermap_validator((ugettext, user): ... ipalib.plugins.selinuxusermap = custom_selinux_usermap_validator ~~~~ Then upgrade would not destroy the change. But of course, things may break as well if for example we change the params of this function. Martin From jhrozek at redhat.com Wed Feb 12 09:30:37 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Feb 2014 10:30:37 +0100 Subject: [Freeipa-users] Unable to access systems In-Reply-To: References: Message-ID: <20140212093037.GF1342@hendrix.redhat.com> On Tue, Feb 11, 2014 at 02:00:56PM -0400, Terry Soucy wrote: > We are transitioning from one IPA instance to a new IPA instance. The > version of IPA instances is the same, and all is functioning normally on > the existing IPA, but when I attempt to transition a host to the new IPA > instance, I get the following in my logs when I attempt an SSH .. > > [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to > 'all'. > [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to > 'all'. > [sssd[be[dev.ca1.sfmc.co]]] [hbac_host_attrs_to_rule] (4): No host > specified, rule will never apply. > [sssd[be[dev.ca1.sfmc.co]]] [hbac_get_category] (5): Category is set to > 'all'. > [sssd[be[dev.ca1.sfmc.co]]] [hbac_host_attrs_to_rule] (4): No host > specified, rule will never apply. > [sssd[be[dev.ca1.sfmc.co]]] [ipa_hbac_evaluate_rules] (3): Access denied by > HBAC rules > [sssd[be[dev.ca1.sfmc.co]]] [be_pam_handler_callback] (4): Backend > returned: (0, 6, ) [Success] Is this all SSSD prints when processing the rules? > > The HBAC rule, according to the test, Does the hbactest utility verify the rule should grant access? If so, then I would recomment upgrading as both hbactest and sssd share the same underlying library (hbactest just uses python bindings). > will grant me access since I'm in the > appropriate group > > Rule name: hbac_techops > Host category: all > Service category: all > Description: TechOps Access > Enabled: TRUE > User Groups: ug-techops > > I'm not sure what "No host specified, rule will never apply" means. Normally this debug message means that the rule being processed contains neither the 'all' category nor a direct host that matches. > I > attempted to add the host to the rule rather than use a hostgroup, but the > result is the same When you say the result is the same, do you also see "No host specified" ? This might sound strange, but are you sure that the client is connecting to the right server and there are no replication issues or similar? You can also verify that the rules that you expect to be downloaded are in fact stored in the sssd cache with: ldbsearch -H /var/lib/sss/db/cache_$domainname (ldbsearch is part of ldb-tools on Fedora/RHEL, not sure what package it is on Ubuntu) > > Server - RH 6.4, ipa-server-3.0.0-37.el6.x86_64 > Client - Ubuntu 10, sssd 1.5.15-0ubuntu6~lucid2 This client is rather old, is there any chance you could try a newer version? There's been a number of fixes for HBAC since 1.5.15, including one crasher bug.. Perhaps Timo Aaltonen might have some newer builds for Lucid in his PPAs. From pviktori at redhat.com Wed Feb 12 09:57:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Feb 2014 10:57:10 +0100 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <52FB3891.3070908@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <52FB3891.3070908@redhat.com> Message-ID: <52FB4576.3000309@redhat.com> Moving to freeipa-devel since we're going rather deep. On 02/12/2014 10:02 AM, Martin Kosek wrote: > On 02/11/2014 08:52 PM, Rob Crittenden wrote: >> Josh wrote: >>> >>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >> > wrote: >>> >>>> Josh wrote: >>>>> I have a situation where I need to support more than 1024 categories >>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>> number of categories I need but ipa still responds with the original >>>>> error message. Do I need to restart any of the services? >>>>> >>>>> Here is the command that was run and the output after applying the >>>>> patch below: >>>>> >>>>> ipa config-mod >>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>> >>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>> >>>> Have you updated your SELinux policy to support a larger MCS range? If >>>> not then this will get you past the IPA validator but it won't work >>>> with SELinux. See semanage(8). >>>> >>>> rob >>> >>> Yes. I?m trying to set the SELinux categories in freeipa because when >>> you have lots of categories all semanage commands slow down (way down). >>> For other people?s knowledge, this requires recompilation of the >>> SELinux policy. >> >> Ok, then your patch looks reasonable. The current code is for the default >> values and we haven't had cause to make this configurable before now. You might >> consider filing a ticket in our trac about this. >> >> Also note that this change will be lost on your next IPA upgrade, and you'll >> need to make this change on any IPA master you want these values to be managed. >> The data will remain unchanged, but the original python values will be restored >> if you update the packages. >> >> I don't believe validators are currently extensible in the IPA framework. That >> might be something we need to look at as well. >> >> regards >> >> rob > > I am thinking you may be able to monkeypatch the validator in a custom plugin, > like selinuxusermap-user.py which would: > > ~~~~ > import ipalib.plugins.selinuxusermap( > > def custom_selinux_usermap_validator((ugettext, user): > ... > > ipalib.plugins.selinuxusermap = custom_selinux_usermap_validator > ~~~~ > > Then upgrade would not destroy the change. But of course, things may break as > well if for example we change the params of this function. > > Martin No, I don't think something like that will work; the validator is baked into the Param on creation. You'd have to replace `selinuxusermap.takes_params` with a copy that has a new `ipaselinuxuser` Param. -- Petr? From genadipost at gmail.com Wed Feb 12 10:15:22 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 12 Feb 2014 12:15:22 +0200 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: <52FB357C.8080307@redhat.com> References: <52FB357C.8080307@redhat.com> Message-ID: What about adding alias DNS record of hostname.ipa.zone.corp to all linux machines, so they will keep the old FQDM. On Feb 12, 2014 10:49 AM, "Martin Kosek" wrote: > On 02/11/2014 07:29 PM, Genadi Postrilko wrote: > > I work in environment where the AD is the DC of the windows machines , > > while the linux machines (RHEL 5\6) are not centrally managed. > > I would like to create an IPA server to manage the linux machines while > > creating a trust with AD. > > The current situation is all windows and linux machines are under > > .zone.corp domain. > >>From what ive read at > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html > , > > i can create trust when IPA is a subdomain of AD domain or when the > > domains are separate. I'm not sure what is the method i should approach. > > Can IPA be a dc inside the AD domain? Or should i create a subdomain for > > linux and then move all the linux machines to the new domain (I hope > not). > > > > Any advice? > > The key here is that for IPA and AD to be able to work together in a trust, > they need to be in separate domains with realm matching this domains. In > your > case, it seems to me that a following scenario would work the best: > > * AD with domain zone.corp and realm ZONE.CORP > * IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP > > Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated > from the AD DNS (or other DNS you use). > > More info here: > http://www.freeipa.org/page/Trusts > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 12 10:32:24 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Feb 2014 12:32:24 +0200 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: References: <52FB357C.8080307@redhat.com> Message-ID: <20140212103224.GK8040@redhat.com> On Wed, 12 Feb 2014, Genadi Postrilko wrote: >What about adding alias DNS record of hostname.ipa.zone.corp to all linux >machines, so they will keep the old FQDM. What would it give to you? AD DC uses FQDN to decide which KDC is responsible to issue TGT (and other tickets). If it belongs to its own DNS domain, no attempt to issue cross-realm TGT will be done and Windows users will never get tickets to services running on these IPA machines. You would really need to address IPA machines by their host names in ipa.zone.corp domain and never by .zone.corp. At this point there is no need to keep them in .zone.corp. >On Feb 12, 2014 10:49 AM, "Martin Kosek" wrote: > >> On 02/11/2014 07:29 PM, Genadi Postrilko wrote: >> > I work in environment where the AD is the DC of the windows machines , >> > while the linux machines (RHEL 5\6) are not centrally managed. >> > I would like to create an IPA server to manage the linux machines while >> > creating a trust with AD. >> > The current situation is all windows and linux machines are under >> > .zone.corp domain. >> >>From what ive read at >> > >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html >> , >> > i can create trust when IPA is a subdomain of AD domain or when the >> > domains are separate. I'm not sure what is the method i should approach. >> > Can IPA be a dc inside the AD domain? Or should i create a subdomain for >> > linux and then move all the linux machines to the new domain (I hope >> not). >> > >> > Any advice? >> >> The key here is that for IPA and AD to be able to work together in a trust, >> they need to be in separate domains with realm matching this domains. In >> your >> case, it seems to me that a following scenario would work the best: >> >> * AD with domain zone.corp and realm ZONE.CORP >> * IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP >> >> Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated >> from the AD DNS (or other DNS you use). >> >> More info here: >> http://www.freeipa.org/page/Trusts >> >> Martin >> >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- / Alexander Bokovoy From pspacek at redhat.com Wed Feb 12 10:45:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Feb 2014 11:45:50 +0100 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: <20140212103224.GK8040@redhat.com> References: <52FB357C.8080307@redhat.com> <20140212103224.GK8040@redhat.com> Message-ID: <52FB50DE.1010702@redhat.com> On 12.2.2014 11:32, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Genadi Postrilko wrote: >> What about adding alias DNS record of hostname.ipa.zone.corp to all linux >> machines, so they will keep the old FQDM. > What would it give to you? > > AD DC uses FQDN to decide which KDC is responsible to issue TGT (and > other tickets). If it belongs to its own DNS domain, no attempt to issue > cross-realm TGT will be done and Windows users will never get tickets to > services running on these IPA machines. > > You would really need to address IPA machines by their host names in > ipa.zone.corp domain and never by .zone.corp. At this point there is no > need to keep them in .zone.corp. Good point. May be that CNAMEs from old name to the new name (in IPA sub-tree) could solve your problem. Kerberos usually follows chain of CNAMEs so it should work. Petr^2 Spacek >> On Feb 12, 2014 10:49 AM, "Martin Kosek" wrote: >> >>> On 02/11/2014 07:29 PM, Genadi Postrilko wrote: >>> > I work in environment where the AD is the DC of the windows machines , >>> > while the linux machines (RHEL 5\6) are not centrally managed. >>> > I would like to create an IPA server to manage the linux machines while >>> > creating a trust with AD. >>> > The current situation is all windows and linux machines are under >>> > .zone.corp domain. >>> >>From what ive read at >>> > >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html >>> >>> , >>> > i can create trust when IPA is a subdomain of AD domain or when the >>> > domains are separate. I'm not sure what is the method i should approach. >>> > Can IPA be a dc inside the AD domain? Or should i create a subdomain for >>> > linux and then move all the linux machines to the new domain (I hope >>> not). >>> > >>> > Any advice? >>> >>> The key here is that for IPA and AD to be able to work together in a trust, >>> they need to be in separate domains with realm matching this domains. In >>> your >>> case, it seems to me that a following scenario would work the best: >>> >>> * AD with domain zone.corp and realm ZONE.CORP >>> * IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP >>> >>> Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated >>> from the AD DNS (or other DNS you use). >>> >>> More info here: >>> http://www.freeipa.org/page/Trusts From sbose at redhat.com Wed Feb 12 11:06:08 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 12 Feb 2014 12:06:08 +0100 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: <52FB50DE.1010702@redhat.com> References: <52FB357C.8080307@redhat.com> <20140212103224.GK8040@redhat.com> <52FB50DE.1010702@redhat.com> Message-ID: <20140212110608.GE19631@localhost.localdomain> On Wed, Feb 12, 2014 at 11:45:50AM +0100, Petr Spacek wrote: > On 12.2.2014 11:32, Alexander Bokovoy wrote: > >On Wed, 12 Feb 2014, Genadi Postrilko wrote: > >>What about adding alias DNS record of hostname.ipa.zone.corp to all linux > >>machines, so they will keep the old FQDM. > >What would it give to you? > > > >AD DC uses FQDN to decide which KDC is responsible to issue TGT (and > >other tickets). If it belongs to its own DNS domain, no attempt to issue > >cross-realm TGT will be done and Windows users will never get tickets to > >services running on these IPA machines. > > > >You would really need to address IPA machines by their host names in > >ipa.zone.corp domain and never by .zone.corp. At this point there is no > >need to keep them in .zone.corp. > > Good point. May be that CNAMEs from old name to the new name (in IPA > sub-tree) could solve your problem. Kerberos usually follows chain > of CNAMEs so it should work. This might work on the DNS level but the local hostname must match as well, because services like e.g. sshd will search their keytab entries with the help of the local hostname. It might be possible to configure the services to use other keytab entries but I think it would be easier to just move all hosts to a new domain then touching the configuration of every single service. bye, Sumit > > Petr^2 Spacek > > >>On Feb 12, 2014 10:49 AM, "Martin Kosek" wrote: > >> > >>>On 02/11/2014 07:29 PM, Genadi Postrilko wrote: > >>>> I work in environment where the AD is the DC of the windows machines , > >>>> while the linux machines (RHEL 5\6) are not centrally managed. > >>>> I would like to create an IPA server to manage the linux machines while > >>>> creating a trust with AD. > >>>> The current situation is all windows and linux machines are under > >>>> .zone.corp domain. > >>>>>From what ive read at > >>>> > >>>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html > >>> > >>>, > >>>> i can create trust when IPA is a subdomain of AD domain or when the > >>>> domains are separate. I'm not sure what is the method i should approach. > >>>> Can IPA be a dc inside the AD domain? Or should i create a subdomain for > >>>> linux and then move all the linux machines to the new domain (I hope > >>>not). > >>>> > >>>> Any advice? > >>> > >>>The key here is that for IPA and AD to be able to work together in a trust, > >>>they need to be in separate domains with realm matching this domains. In > >>>your > >>>case, it seems to me that a following scenario would work the best: > >>> > >>>* AD with domain zone.corp and realm ZONE.CORP > >>>* IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP > >>> > >>>Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated > >>>from the AD DNS (or other DNS you use). > >>> > >>>More info here: > >>>http://www.freeipa.org/page/Trusts > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbose at redhat.com Wed Feb 12 12:02:00 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 12 Feb 2014 13:02:00 +0100 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts In-Reply-To: References: <20140210160900.GA2635@localhost.localdomain> Message-ID: <20140212120200.GF19631@localhost.localdomain> On Mon, Feb 10, 2014 at 02:08:22PM -0500, Steve Dainard wrote: > Sure: > ... > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [validate_tgt] > (0x0400): TGT verified using key for > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [become_user] > (0x0200): Trying to become user [799001323][799001323]. ... > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > (Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929]]]] [validate_tgt] > (0x0400): TGT verified using key for > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [become_user] > (0x0200): Trying to become user [799001323][799001323]. ... > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [validate_tgt] > (0x0400): TGT verified using key for > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [become_user] > (0x0200): Trying to become user [799001323][799001323]. ... > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > (Mon Feb 10 10:17:30 2014) [[sssd[krb5_child[10018]]]] [validate_tgt] > (0x0400): TGT verified using key for > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018]]]] [become_user] > (0x0200): Trying to become user [799001323][799001323]. as you can see the time is spend to validate the ticket. For a user from a trusted domain this includes a request for a cross-realm TGT to a AD server and then a request to an IPA KDC for a service ticket for the local host. With debug_level 9 and higher the libkrb5 tracing is switched on which would in more detail show where the time is lost. It will also show which AD server is contacted. You mentioned in your other mail that with a different client the logins are faster. Are the two clients in the same network segment? Or is there a chance that the other client is "nearer" to the AD server? bye, Sumit From tompos at martos.bme.hu Wed Feb 12 12:02:56 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 13:02:56 +0100 Subject: [Freeipa-users] authentication against compat Message-ID: <52FB62F0.7060607@martos.bme.hu> hi All, $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w `cat pw` ldap_bind: Referral (10) referrals: ldap:///uid=USER,cn=users,cn=accounts,dc=foo [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from ::1 to ::1 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 nentries=0 etime=0 [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). Non-compat authentication works fine and authorization against compat is also fine. What is err=10? Any idea? Thanks, tamas From abokovoy at redhat.com Wed Feb 12 12:07:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Feb 2014 14:07:45 +0200 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB62F0.7060607@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> Message-ID: <20140212120745.GM8040@redhat.com> On Wed, 12 Feb 2014, Tamas Papp wrote: >hi All, > >$ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >`cat pw` >ldap_bind: Referral (10) > referrals: > ldap:///uid=USER,cn=users,cn=accounts,dc=foo > > > > >[12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >::1 to ::1 >[12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >[12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >nentries=0 etime=0 >[12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 > > >System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >Non-compat authentication works fine and authorization against compat is >also fine. > > >What is err=10? slapi-nis module in RHEL 6.x (and CentOS) does not support bind against compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). In older versions slapi-nis issues LDAP referral to the original LDAP entry with the hope that an LDAP client would follow it and perform a bind against the referral. Unfortunately, there is virtually no client software that supports the referral on bind operation. In short, you cannot do LDAP bind against compat tree in RHEL before 7.0. -- / Alexander Bokovoy From tompos at martos.bme.hu Wed Feb 12 12:17:57 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 13:17:57 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212120745.GM8040@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> Message-ID: <52FB6675.5010503@martos.bme.hu> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Tamas Papp wrote: >> hi All, >> >> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >> `cat pw` >> ldap_bind: Referral (10) >> referrals: >> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >> >> >> >> >> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >> ::1 to ::1 >> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >> nentries=0 etime=0 >> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >> >> >> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >> Non-compat authentication works fine and authorization against compat is >> also fine. >> >> >> What is err=10? > slapi-nis module in RHEL 6.x (and CentOS) does not support bind against > compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). > > In older versions slapi-nis issues LDAP referral to the original LDAP > entry with the hope that an LDAP client would follow it and perform a > bind against the referral. > > Unfortunately, there is virtually no client software that supports the > referral on bind operation. > > In short, you cannot do LDAP bind against compat tree in RHEL before > 7.0. I forgot to mention, the client would be Ubuntu 12.04 and it works/worked with IPA 3.3 and F20. If I understand correctly, you're referring to the client side, are you? Or it is true for the server side as well? Thanks, tamas From abokovoy at redhat.com Wed Feb 12 12:34:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Feb 2014 14:34:06 +0200 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB6675.5010503@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> Message-ID: <20140212123406.GN8040@redhat.com> On Wed, 12 Feb 2014, Tamas Papp wrote: > >On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >> On Wed, 12 Feb 2014, Tamas Papp wrote: >>> hi All, >>> >>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >>> `cat pw` >>> ldap_bind: Referral (10) >>> referrals: >>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>> >>> >>> >>> >>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >>> ::1 to ::1 >>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>> nentries=0 etime=0 >>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>> >>> >>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>> Non-compat authentication works fine and authorization against compat is >>> also fine. >>> >>> >>> What is err=10? >> slapi-nis module in RHEL 6.x (and CentOS) does not support bind against >> compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). >> >> In older versions slapi-nis issues LDAP referral to the original LDAP >> entry with the hope that an LDAP client would follow it and perform a >> bind against the referral. >> >> Unfortunately, there is virtually no client software that supports the >> referral on bind operation. >> >> In short, you cannot do LDAP bind against compat tree in RHEL before >> 7.0. > >I forgot to mention, the client would be Ubuntu 12.04 and it >works/worked with IPA 3.3 and F20. It worked with IPA 3.3 because of what I wrote above -- I implemented LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP referral to the original entry's DN. >If I understand correctly, you're referring to the client side, are you? No. >Or it is true for the server side as well? It is purely server-side issue. slapi-nis < 0.47.5 does not support proper authentication against compat tree that LDAP clients understand. -- / Alexander Bokovoy From tompos at martos.bme.hu Wed Feb 12 12:35:44 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 13:35:44 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212123406.GN8040@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> Message-ID: <52FB6AA0.60707@martos.bme.hu> On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Tamas Papp wrote: >> >> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>> hi All, >>>> >>>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >>>> `cat pw` >>>> ldap_bind: Referral (10) >>>> referrals: >>>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>>> >>>> >>>> >>>> >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >>>> ::1 to ::1 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>>> nentries=0 etime=0 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>>> >>>> >>>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>>> Non-compat authentication works fine and authorization against >>>> compat is >>>> also fine. >>>> >>>> >>>> What is err=10? >>> slapi-nis module in RHEL 6.x (and CentOS) does not support bind against >>> compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). >>> >>> In older versions slapi-nis issues LDAP referral to the original LDAP >>> entry with the hope that an LDAP client would follow it and perform a >>> bind against the referral. >>> >>> Unfortunately, there is virtually no client software that supports the >>> referral on bind operation. >>> >>> In short, you cannot do LDAP bind against compat tree in RHEL before >>> 7.0. >> >> I forgot to mention, the client would be Ubuntu 12.04 and it >> works/worked with IPA 3.3 and F20. > It worked with IPA 3.3 because of what I wrote above -- I implemented > LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP > referral to the original entry's DN. > >> If I understand correctly, you're referring to the client side, are you? > No. > >> Or it is true for the server side as well? > It is purely server-side issue. slapi-nis < 0.47.5 does not support > proper authentication against compat tree that LDAP clients understand. OK, that's clear now. Sorry I wasn't aware of slapi-nis behaviour:) Thanks, tamas From rcritten at redhat.com Wed Feb 12 13:42:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Feb 2014 08:42:23 -0500 Subject: [Freeipa-users] By default on port 389 , any encryption between client and server In-Reply-To: References: Message-ID: <52FB7A3F.6010209@redhat.com> barrykfl at gmail.com wrote: > Hi all: > Some doc said it already build in TLS on 389 ... is it nsslapd-minssf on > the dse.ldif? Yes. > Should i need to set 636 ldaps ? or set higher nsslapd-minssf enough? Higher minssf should be enough. It will require GSSAPI or startTLS on a connection. > What document tell the default secure connection of free ipa? I don't believe we have everything in one place. The LDAP security settings are available at https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html rob From tompos at martos.bme.hu Wed Feb 12 14:01:42 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 15:01:42 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212123406.GN8040@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> Message-ID: <52FB7EC6.4020107@martos.bme.hu> On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Tamas Papp wrote: >> >> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>> hi All, >>>> >>>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >>>> `cat pw` >>>> ldap_bind: Referral (10) >>>> referrals: >>>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>>> >>>> >>>> >>>> >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >>>> ::1 to ::1 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>>> nentries=0 etime=0 >>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>>> >>>> >>>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>>> Non-compat authentication works fine and authorization against >>>> compat is >>>> also fine. >>>> >>>> >>>> What is err=10? >>> slapi-nis module in RHEL 6.x (and CentOS) does not support bind against >>> compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). >>> >>> In older versions slapi-nis issues LDAP referral to the original LDAP >>> entry with the hope that an LDAP client would follow it and perform a >>> bind against the referral. >>> >>> Unfortunately, there is virtually no client software that supports the >>> referral on bind operation. >>> >>> In short, you cannot do LDAP bind against compat tree in RHEL before >>> 7.0. >> >> I forgot to mention, the client would be Ubuntu 12.04 and it >> works/worked with IPA 3.3 and F20. > It worked with IPA 3.3 because of what I wrote above -- I implemented > LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP > referral to the original entry's DN. > >> If I understand correctly, you're referring to the client side, are you? > No. > >> Or it is true for the server side as well? > It is purely server-side issue. slapi-nis < 0.47.5 does not support > proper authentication against compat tree that LDAP clients understand. Actually I'd like to authenticate shell users on Ubuntu. For the records I figured out, that switching from nscd to nslcd did the trick. Thanks, tamas From pspacek at redhat.com Wed Feb 12 14:04:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Feb 2014 15:04:24 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB7EC6.4020107@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> Message-ID: <52FB7F68.9030008@redhat.com> On 12.2.2014 15:01, Tamas Papp wrote: > > On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: >> On Wed, 12 Feb 2014, Tamas Papp wrote: >>> >>> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >>>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>>> hi All, >>>>> >>>>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h localhost -w >>>>> `cat pw` >>>>> ldap_bind: Referral (10) >>>>> referrals: >>>>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>>>> >>>>> >>>>> >>>>> >>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection from >>>>> ::1 to ::1 >>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>>>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>>>> nentries=0 etime=0 >>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>>>> >>>>> >>>>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>>>> Non-compat authentication works fine and authorization against >>>>> compat is >>>>> also fine. >>>>> >>>>> >>>>> What is err=10? >>>> slapi-nis module in RHEL 6.x (and CentOS) does not support bind against >>>> compat tree. We added this feature only in Fedora 20 (and RHEL 7 beta). >>>> >>>> In older versions slapi-nis issues LDAP referral to the original LDAP >>>> entry with the hope that an LDAP client would follow it and perform a >>>> bind against the referral. >>>> >>>> Unfortunately, there is virtually no client software that supports the >>>> referral on bind operation. >>>> >>>> In short, you cannot do LDAP bind against compat tree in RHEL before >>>> 7.0. >>> >>> I forgot to mention, the client would be Ubuntu 12.04 and it >>> works/worked with IPA 3.3 and F20. >> It worked with IPA 3.3 because of what I wrote above -- I implemented >> LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing LDAP >> referral to the original entry's DN. >> >>> If I understand correctly, you're referring to the client side, are you? >> No. >> >>> Or it is true for the server side as well? >> It is purely server-side issue. slapi-nis < 0.47.5 does not support >> proper authentication against compat tree that LDAP clients understand. > > Actually I'd like to authenticate shell users on Ubuntu. > > For the records I figured out, that switching from nscd to nslcd did the > trick. BTW why you don't use SSSD? It is packaged for Ubuntu for sure. NSCD is ... obsolete. SSSD has some very nice features like off-line cache etc. -- Petr^2 Spacek From tompos at martos.bme.hu Wed Feb 12 14:30:15 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 15:30:15 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB7F68.9030008@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> Message-ID: <52FB8577.3010601@martos.bme.hu> On 02/12/2014 03:04 PM, Petr Spacek wrote: > On 12.2.2014 15:01, Tamas Papp wrote: >> >> On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: >>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>> >>>> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >>>>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>>>> hi All, >>>>>> >>>>>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h >>>>>> localhost -w >>>>>> `cat pw` >>>>>> ldap_bind: Referral (10) >>>>>> referrals: >>>>>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection >>>>>> from >>>>>> ::1 to ::1 >>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>>>>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>>>>> nentries=0 etime=0 >>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>>>>> >>>>>> >>>>>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>>>>> Non-compat authentication works fine and authorization against >>>>>> compat is >>>>>> also fine. >>>>>> >>>>>> >>>>>> What is err=10? >>>>> slapi-nis module in RHEL 6.x (and CentOS) does not support bind >>>>> against >>>>> compat tree. We added this feature only in Fedora 20 (and RHEL 7 >>>>> beta). >>>>> >>>>> In older versions slapi-nis issues LDAP referral to the original LDAP >>>>> entry with the hope that an LDAP client would follow it and perform a >>>>> bind against the referral. >>>>> >>>>> Unfortunately, there is virtually no client software that supports >>>>> the >>>>> referral on bind operation. >>>>> >>>>> In short, you cannot do LDAP bind against compat tree in RHEL before >>>>> 7.0. >>>> >>>> I forgot to mention, the client would be Ubuntu 12.04 and it >>>> works/worked with IPA 3.3 and F20. >>> It worked with IPA 3.3 because of what I wrote above -- I implemented >>> LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing >>> LDAP >>> referral to the original entry's DN. >>> >>>> If I understand correctly, you're referring to the client side, are >>>> you? >>> No. >>> >>>> Or it is true for the server side as well? >>> It is purely server-side issue. slapi-nis < 0.47.5 does not support >>> proper authentication against compat tree that LDAP clients understand. >> >> Actually I'd like to authenticate shell users on Ubuntu. >> >> For the records I figured out, that switching from nscd to nslcd did the >> trick. > > BTW why you don't use SSSD? It is packaged for Ubuntu for sure. NSCD > is ... obsolete. SSSD has some very nice features like off-line cache > etc. I don't know it. After a quick look I wasn't able to set it up correctly, 'id USER' didn't connected to it's socket like with nscd/nlscd, however nsswitch.conf was configured. Maybe with the upcoming 14.04 or do you have a working howto for 12.04? Thx, tamas From sdainard at miovision.com Wed Feb 12 16:21:36 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 12 Feb 2014 11:21:36 -0500 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts Message-ID: +Ovirt users mailing list - might find this interesting. Quick background: IPA server with cross-forest trust to Windows domain. Authenticating to Linux clients with domain kerberos credentials. I'm hosting CentOS 6.5 as an ovirt guest, and have narrowed this ipa client slow login issue down to a backend storage cause. If I enable async writes to NFS the CentOS guest performs as my workstations virtualbox guests (Ubuntu 13.10/Fedora 20) do on login (quick logins). The client we are investigating is a CentOS 6.5 machine. I've also done the same test on a RHEL 6.5 machine with the same results. I've increased the logging level, log attached. I don't see the DC in the logs anywhere. I guess from an IPA perspective there is not much to be done, but I wanted to make sure this thread came to some conclusion for future readers. I suppose the only thing to question, is why ipa authentication would have any reliance on disk read/write speed to this extent? Perhaps we are caching something to disk that should be cached in memory? *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 12, 2014 at 7:02 AM, Sumit Bose wrote: > On Mon, Feb 10, 2014 at 02:08:22PM -0500, Steve Dainard wrote: > > Sure: > > > > ... > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [validate_tgt] > > (0x0400): TGT verified using key for > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [become_user] > > (0x0200): Trying to become user [799001323][799001323]. > > ... > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > (Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929]]]] [validate_tgt] > > (0x0400): TGT verified using key for > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [become_user] > > (0x0200): Trying to become user [799001323][799001323]. > > ... > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [validate_tgt] > > (0x0400): TGT verified using key for > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [become_user] > > (0x0200): Trying to become user [799001323][799001323]. > > ... > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > (Mon Feb 10 10:17:30 2014) [[sssd[krb5_child[10018]]]] [validate_tgt] > > (0x0400): TGT verified using key for > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018]]]] [become_user] > > (0x0200): Trying to become user [799001323][799001323]. > > as you can see the time is spend to validate the ticket. For a user from > a trusted domain this includes a request for a cross-realm TGT to a AD > server and then a request to an IPA KDC for a service ticket for the > local host. With debug_level 9 and higher the libkrb5 tracing is > switched on which would in more detail show where the time is lost. It > will also show which AD server is contacted. > > You mentioned in your other mail that with a different client the logins > are faster. Are the two clients in the same network segment? Or is there > a chance that the other client is "nearer" to the AD server? > > bye, > Sumit > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rhel6-client.sssd_miolinux.corp.log Type: text/x-log Size: 285563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: centos6-client.sssd_miolinux.corp.log Type: text/x-log Size: 147329 bytes Desc: not available URL: From sbose at redhat.com Wed Feb 12 17:05:32 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 12 Feb 2014 18:05:32 +0100 Subject: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts In-Reply-To: References: Message-ID: <20140212170532.GJ19631@localhost.localdomain> On Wed, Feb 12, 2014 at 11:21:36AM -0500, Steve Dainard wrote: > +Ovirt users mailing list - might find this interesting. Quick background: > IPA server with cross-forest trust to Windows domain. Authenticating to > Linux clients with domain kerberos credentials. > > I'm hosting CentOS 6.5 as an ovirt guest, and have narrowed this ipa client > slow login issue down to a backend storage cause. If I enable async writes > to NFS the CentOS guest performs as my workstations virtualbox guests > (Ubuntu 13.10/Fedora 20) do on login (quick logins). > > The client we are investigating is a CentOS 6.5 machine. I've also done the > same test on a RHEL 6.5 machine with the same results. I've increased the > logging level, log attached. I don't see the DC in the logs anywhere. sorry for not being clear, I meant the krb5_child log files. > > I guess from an IPA perspective there is not much to be done, but I wanted > to make sure this thread came to some conclusion for future readers. I > suppose the only thing to question, is why ipa authentication would have > any reliance on disk read/write speed to this extent? Perhaps we are > caching something to disk that should be cached in memory? no, I think this is quite surprising. There are a lot of other operations which have more higher requirements on I/O than Kerberos ticket validation. Let's see if the krb5_child logs show any more details. bye, Sumit > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | *Rethink Traffic* > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, > Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Wed, Feb 12, 2014 at 7:02 AM, Sumit Bose wrote: > > > On Mon, Feb 10, 2014 at 02:08:22PM -0500, Steve Dainard wrote: > > > Sure: > > > > > > > ... > > > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > > (Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879]]]] [validate_tgt] > > > (0x0400): TGT verified using key for > > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > > (Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879]]]] [become_user] > > > (0x0200): Trying to become user [799001323][799001323]. > > > > ... > > > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > > (Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929]]]] [validate_tgt] > > > (0x0400): TGT verified using key for > > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > > (Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929]]]] [become_user] > > > (0x0200): Trying to become user [799001323][799001323]. > > > > ... > > > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > > (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960]]]] [validate_tgt] > > > (0x0400): TGT verified using key for > > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > > (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960]]]] [become_user] > > > (0x0200): Trying to become user [799001323][799001323]. > > > > ... > > > > > (0x0400): Attempting kinit for realm [MIOVISION.CORP] > > > (Mon Feb 10 10:17:30 2014) [[sssd[krb5_child[10018]]]] [validate_tgt] > > > (0x0400): TGT verified using key for > > > [host/snapshot-test.miolinux.corp at MIOLINUX.CORP]. > > > (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018]]]] [become_user] > > > (0x0200): Trying to become user [799001323][799001323]. > > > > as you can see the time is spend to validate the ticket. For a user from > > a trusted domain this includes a request for a cross-realm TGT to a AD > > server and then a request to an IPA KDC for a service ticket for the > > local host. With debug_level 9 and higher the libkrb5 tracing is > > switched on which would in more detail show where the time is lost. It > > will also show which AD server is contacted. > > > > You mentioned in your other mail that with a different client the logins > > are faster. Are the two clients in the same network segment? Or is there > > a chance that the other client is "nearer" to the AD server? > > > > bye, > > Sumit > > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [resolv_get_family_order] (0x1000): Lookup order: ipv4_first > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [fo_context_init] (0x0400): Created new fail over context, retry timeout is 30 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [confdb_get_domain_internal] (0x0400): No enumeration for [miolinux.corp]! > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sysdb_domain_init_internal] (0x0200): DB File for miolinux.corp: /var/lib/sss/db/cache_miolinux.corp.ldb > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x828b90 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x83df70 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x828b90 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x83df70 "ltdb_timeout" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x828b90 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x0400): asq: Unable to register control with rootdse! > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83b960 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x83d110 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83b960 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x83d110 "ltdb_timeout" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83b960 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83e040 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x83e0f0 > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83e040 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x83e0f0 "ltdb_timeout" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83e040 "ltdb_callback" > > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_init_connection] (0x0200): Adding connection 83E740 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x83ec60/0x828c30 (15), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c80 (15), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [monitor_common_send_id] (0x0100): Sending ID: (%BE_miolinux.corp,1) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_timeout] (0x2000): 0x828610 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c80 (15), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c30 (15), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sss_names_init] (0x0100): Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [create_socket_symlink] (0x1000): Symlinking the dbus path /var/lib/sss/pipes/private/sbus-dp_miolinux.corp.2375 to a link /var/lib/sss/pipes/private/sbus-dp_miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_new_server] (0x0400): D-BUS Server listening on unix:path=/var/lib/sss/pipes/private/sbus-dp_miolinux.corp.2375,guid=bf9c3d123cb8c3308796319e000000db > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x83f9f0/0x83c300 (16), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Loading backend [ipa] with path [/usr/lib64/sssd/libsss_ipa.so]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_domain has value miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_server has value _srv_, ipa1.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_hostname has value rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_dyndns_update is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_dyndns_iface has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_hbac_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_host_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_selinux_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_subdomains_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_master_domain_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_hbac_refresh has value 5 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_hbac_treat_deny_as has value DENY_ALL > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_hbac_support_srchost is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_automount_location has value default > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ipa_ranges_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [fo_new_service] (0x0400): Creating new service 'IPA' > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [fo_add_srv_server] (0x0400): Adding new SRV server to service 'IPA' using 'tcp'. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_servers_init] (0x0400): Added service lookup for service IPA > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [fo_add_server] (0x0080): Adding new server 'ipa1.miolinux.corp', to service 'IPA' > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_servers_init] (0x0400): Added Server ipa1.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_backup_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_bind_dn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_authtok_type has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_authtok has no binary value. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_search_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_network_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_opt_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_reqcert has value hard > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_scope has value sub > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_scope has value sub > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_service_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_full_refresh_interval has value 21600 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_smart_refresh_interval has value 900 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_use_host_filter is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_hostnames has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_ip has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_include_netgroups is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_include_regexp is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_autofs_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_schema has value ipa_v1 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_offline_timeout has value 60 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_force_upper_case_realm is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_enumeration_refresh_timeout has value 300 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_purge_cache_timeout has value 3600 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cacert has value /etc/ipa/ca.crt > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cacertdir has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cert has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_key has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cipher_suite has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_id_use_start_tls is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_id_mapping is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_mech has value GSSAPI > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_authid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_minssf has value 56 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_keytab has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_init_creds is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_canonicalize is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_pwd_policy has value none > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_referrals is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option account_cache_expiration has value 0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_dns_service_name has value ldap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_ticket_lifetime has value 86400 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_access_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_netgroup_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_nesting_level has value 2 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_deref has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_account_expire_policy has value ipa > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_access_order has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_backup_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_dns_service_name has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_update_last_change is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 60 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_auth_disable_tls_never_use_in_production is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_page_size has value 1000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_deref_threshold has value 10 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_canonicalize is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_connection_expire_timeout has value 900 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_disable_paging is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_min has value 200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_max has value 2000200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_size has value 200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_autorid_compat is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_default_domain has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_default_domain_sid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_groups_use_matching_rule_in_chain is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_initgroups_use_matching_rule_in_chain is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_rfc2307_fallback_to_local_users is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_disable_range_retrieval is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option krb5_realm set to MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Will look for rhel6-client.miolinux.corp at MIOLINUX.CORP in default keytab > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal rhel6-client.miolinux.corp at MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x0400): No principal matching rhel6-client.miolinux.corp at MIOLINUX.CORP found in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal RHEL6-CLIENT$@MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x0400): No principal matching RHEL6-CLIENT$@MIOLINUX.CORP found in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/rhel6-client.miolinux.corp at MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [match_principal] (0x1000): Principal matched to the sample (host/rhel6-client.miolinux.corp at MIOLINUX.CORP). > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): Selected primary: host/rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): Selected realm: MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to host/rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_user_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [USER][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_group_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [GROUP][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_sudo_search_base set to ou=SUDOers,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][ou=SUDOers,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_netgroup_search_base set to cn=ng,cn=alt,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][cn=ng,cn=alt,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0100): Option ipa_host_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_HOST][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ipa_hbac_search_base set to cn=hbac,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_HBAC][cn=hbac,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0100): Option ipa_selinux_search_base set to cn=selinux,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_SELINUX][cn=selinux,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_group_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0100): Option ipa_subdomains_search_base set to cn=trusts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_SUBDOMAINS][cn=trusts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0100): Option ipa_master_domain_search_base set to cn=ad,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_MASTER_DOMAIN][cn=ad,cn=etc,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0100): Option ipa_ranges_search_base set to cn=ranges,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_RANGES][cn=ranges,cn=etc,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_entry_usn has value entryUSN > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_rootdse_last_usn has value lastUSN > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_object_class has value posixAccount > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_name has value uid > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_pwd has value userPassword > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_uid_number has value uidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_gid_number has value gidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_gecos has value gecos > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_home_directory has value homeDirectory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shell has value loginShell > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_principal has value krbPrincipalName > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_fullname has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_uuid has value nsUniqueId > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_objectsid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_primary_group has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_modify_timestamp has value modifyTimestamp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_last_change has value shadowLastChange > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_min has value shadowMin > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_max has value shadowMax > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_warning has value shadowWarning > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_inactive has value shadowInactive > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_expire has value shadowExpire > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_flag has value shadowFlag > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_krb_password_expiration has value krbPasswordExpiration > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_pwd_attribute has value pwdAttribute > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_authorized_service has value authorizedService > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ad_account_expires has value accountExpires > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ad_user_account_control has value userAccountControl > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_ns_account_lock has value nsAccountLock > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_authorized_host has value host > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_disabled has value loginDisabled > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_expiration_time has value loginExpirationTime > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_allowed_time_map has value loginAllowedTimeMap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ssh_public_key has value ipaSshPubKey > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_object_class has value posixGroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_pwd has value userPassword > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_gid_number has value gidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_member has value member > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_uuid has value nsUniqueId > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_objectsid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_modify_timestamp has value modifyTimestamp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_object_class has value ipaNisNetgroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member has value member > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_user has value memberUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_host has value memberHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_ext_host has value externalHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_domain has value nisDomainName > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_object_class has value ipaHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_fqdn has value fqdn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_serverhostname has value serverHostname > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_ssh_public_key has value ipaSshPubKey > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_objectclass has value ipaHostgroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_memberof has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_object_class has value ipService > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_port has value ipServicePort > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_proto has value ipServiceProtocol > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_object_class has value ipaselinuxusermap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_member_user has value memberUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_member_host has value memberHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_see_also has value seeAlso > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_selinux_user has value ipaSELinuxUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_enabled has value ipaEnabledFlag > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_user_category has value userCategory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_host_category has value hostCategory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at 1392219003.221753 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x2000): ID backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_domain has value miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_server has value _srv_, ipa1.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hostname has value rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_dyndns_update is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_dyndns_iface has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_search_base has value cn=hbac,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_host_search_base has value cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_subdomains_search_base has value cn=trusts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_master_domain_search_base has value cn=ad,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option krb5_realm has value MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_refresh has value 5 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_treat_deny_as has value DENY_ALL > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_support_srchost is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_automount_location has value default > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_ranges_search_base has value cn=ranges,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_ccachedir has value /tmp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_ccname_template has value FILE:%d/krb5cc_%U_XXXXXX > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_auth_timeout has value 15 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_keytab has value /etc/krb5.keytab > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_validate is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_kpasswd has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_backup_kpasswd has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_store_password_if_offline is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_renewable_lifetime has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_lifetime has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_renew_interval has value 0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_use_fast has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_fast_principal has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_canonicalize is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [krb5_try_kdcip] (0x0100): No KDC found in configuration, trying legacy option > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_auth_options] (0x0400): Option krb5_realm set to MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_backup_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_bind_dn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_authtok_type has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_default_authtok has no binary value. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_search_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_network_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_opt_timeout has value 6 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_reqcert has value hard > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_scope has value sub > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_user_search_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_scope has value sub > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_search_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_service_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_full_refresh_interval has value 21600 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_smart_refresh_interval has value 900 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_use_host_filter is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_hostnames has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_ip has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_include_netgroups is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sudo_include_regexp is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_autofs_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_schema has value ipa_v1 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_offline_timeout has value 60 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_force_upper_case_realm is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_enumeration_refresh_timeout has value 300 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_purge_cache_timeout has value 3600 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cacert has value /etc/ipa/ca.crt > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cacertdir has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cert has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_key has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_tls_cipher_suite has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_id_use_start_tls is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_id_mapping is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_mech has value GSSAPI > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_authid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_minssf has value 56 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_keytab has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_init_creds is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_realm has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option krb5_canonicalize is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_pwd_policy has value none > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_referrals is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option account_cache_expiration has value 0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_dns_service_name has value ldap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_krb5_ticket_lifetime has value 86400 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_access_filter has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_netgroup_search_base has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_group_nesting_level has value 2 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_deref has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_account_expire_policy has value ipa > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_access_order has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_backup_uri has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_dns_service_name has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_chpass_update_last_change is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 60 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_auth_disable_tls_never_use_in_production is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_page_size has value 1000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_deref_threshold has value 10 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_sasl_canonicalize is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_connection_expire_timeout has value 900 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_disable_paging is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_min has value 200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_max has value 2000200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_range_size has value 200000 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_autorid_compat is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_default_domain has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_idmap_default_domain_sid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_groups_use_matching_rule_in_chain is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_initgroups_use_matching_rule_in_chain is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_rfc2307_fallback_to_local_users is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_get_options] (0x0400): Option ldap_disable_range_retrieval is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [DEFAULT][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option krb5_realm set to MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Will look for rhel6-client.miolinux.corp at MIOLINUX.CORP in default keytab > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal rhel6-client.miolinux.corp at MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x0400): No principal matching rhel6-client.miolinux.corp at MIOLINUX.CORP found in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal RHEL6-CLIENT$@MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x0400): No principal matching RHEL6-CLIENT$@MIOLINUX.CORP found in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/rhel6-client.miolinux.corp at MIOLINUX.CORP in keytab. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [match_principal] (0x1000): Principal matched to the sample (host/rhel6-client.miolinux.corp at MIOLINUX.CORP). > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): Selected primary: host/rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [select_principal_from_keytab] (0x0200): Selected realm: MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to host/rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_user_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [USER][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_group_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [GROUP][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_sudo_search_base set to ou=SUDOers,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][ou=SUDOers,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_netgroup_search_base set to cn=ng,cn=alt,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [NETGROUP][cn=ng,cn=alt,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_HOST][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_HBAC][cn=hbac,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_SELINUX][cn=selinux,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_id_options] (0x0400): Option ldap_group_search_base set to cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [SERVICE][cn=accounts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_SUBDOMAINS][cn=trusts,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_MASTER_DOMAIN][cn=ad,cn=etc,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [IPA_RANGES][cn=ranges,cn=etc,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_entry_usn has value entryUSN > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_rootdse_last_usn has value lastUSN > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_object_class has value posixAccount > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_name has value uid > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_pwd has value userPassword > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_uid_number has value uidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_gid_number has value gidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_gecos has value gecos > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_home_directory has value homeDirectory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shell has value loginShell > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_principal has value krbPrincipalName > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_fullname has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_uuid has value nsUniqueId > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_objectsid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_primary_group has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_modify_timestamp has value modifyTimestamp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_last_change has value shadowLastChange > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_min has value shadowMin > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_max has value shadowMax > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_warning has value shadowWarning > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_inactive has value shadowInactive > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_expire has value shadowExpire > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_shadow_flag has value shadowFlag > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_krb_last_pwd_change has value krbLastPwdChange > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_krb_password_expiration has value krbPasswordExpiration > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_pwd_attribute has value pwdAttribute > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_authorized_service has value authorizedService > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ad_account_expires has value accountExpires > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ad_user_account_control has value userAccountControl > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_ns_account_lock has value nsAccountLock > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_authorized_host has value host > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_disabled has value loginDisabled > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_expiration_time has value loginExpirationTime > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_nds_login_allowed_time_map has value loginAllowedTimeMap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_user_ssh_public_key has value ipaSshPubKey > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_object_class has value posixGroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_pwd has value userPassword > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_gid_number has value gidNumber > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_member has value member > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_uuid has value nsUniqueId > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_objectsid has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_modify_timestamp has value modifyTimestamp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_group_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_object_class has value ipaNisNetgroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member has value member > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_user has value memberUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_host has value memberHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_member_ext_host has value externalHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_domain has value nisDomainName > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_netgroup_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_object_class has value ipaHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_fqdn has value fqdn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_serverhostname has value serverHostname > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_member_of has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_ssh_public_key has value ipaSshPubKey > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_host_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_objectclass has value ipaHostgroup > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_memberof has value memberOf > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_hostgroup_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_object_class has value ipService > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_port has value ipServicePort > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_proto has value ipServiceProtocol > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_service_entry_usn has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_object_class has value ipaselinuxusermap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_name has value cn > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_member_user has value memberUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_member_host has value memberHost > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_see_also has value seeAlso > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_selinux_user has value ipaSELinuxUser > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_enabled has value ipaEnabledFlag > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_user_category has value userCategory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_host_category has value hostCategory > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ipa_selinux_usermap_uuid has value ipaUniqueID > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [check_and_export_lifetime] (0x0200): No lifetime configured. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [check_and_export_lifetime] (0x0200): No lifetime configured. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [check_and_export_options] (0x0100): No KDC explicitly configured, using defaults. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [check_and_export_options] (0x0100): No kpasswd server explicitly configured, using the KDC or defaults. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [check_and_export_options] (0x0100): ccache is of type FILE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x2000): AUTH backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_domain has value miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_server has value _srv_, ipa1.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_backup_server has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hostname has value rhel6-client.miolinux.corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_dyndns_update is TRUE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_dyndns_iface has no value > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_search_base has value cn=hbac,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_host_search_base has value cn=accounts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_subdomains_search_base has value cn=trusts,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_master_domain_search_base has value cn=ad,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option krb5_realm has value MIOLINUX.CORP > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_refresh has value 5 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_treat_deny_as has value DENY_ALL > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_hbac_support_srchost is FALSE > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_automount_location has value default > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [dp_copy_options] (0x0400): Option ipa_ranges_search_base has value cn=ranges,cn=etc,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x2000): ACCESS backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x2000): CHPASS backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init_sudo] (0x0400): SUDO is not listed in services, disabling SUDO module. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x0080): No SUDO module provided for [miolinux.corp] !! > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x0200): no module name found in confdb, using [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sssm_ipa_autofs_init] (0x2000): Initializing IPA autofs handler > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_autofs_init] (0x2000): Initializing autofs LDAP back end > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_autofs_options] (0x1000): Option ldap_autofs_search_base set to cn=default,cn=automount,dc=miolinux,dc=corp > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][cn=default,cn=automount,dc=miolinux,dc=corp][SUBTREE][] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_autofs_map_object_class has value automountMap > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_autofs_map_name has value automountMapName > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_autofs_entry_object_class has value automount > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_autofs_entry_key has value automountKey > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sdap_get_map] (0x0400): Option ldap_autofs_entry_value has value automountInformation > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x2000): autofs backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x0200): no module name found in confdb, using [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x4000): selinux backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x0200): no module name found in confdb, using [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x4000): HOST backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x0200): no module name found in confdb, using [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [load_backend_module] (0x1000): Backend [ipa] already loaded. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [get_config_status] (0x4000): IPA subdomain provider is configured implicit. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_process_init] (0x4000): Get-Subdomains backend target successfully loaded from provider [ipa]. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [main] (0x0400): Backend provider (miolinux.corp) started! > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c80 (15), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c30 (15), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c80 (15), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83ec60/0x828c30 (15), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_remove_timeout] (0x2000): 0x828610 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Entering. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x867a00. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_init_connection] (0x0200): Adding connection 867A00 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x8674d0/0x83ef70 (19), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x8674d0/0x85f9d0 (19), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Got a connection > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x83eda0] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Entering. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x868090. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_init_connection] (0x0200): Adding connection 868090 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x83e380/0x867ea0 (20), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83e380/0x8659c0 (20), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Got a connection > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x86bfa0] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x8674d0/0x85f9d0 (19), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x8674d0/0x83ef70 (19), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Entering. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x86dbc0. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_init_connection] (0x0200): Adding connection 86DBC0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x86e2a0/0x86cd90 (21), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86e2a0/0x86ca30 (21), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Got a connection > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x86e510] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86DBC0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83e380/0x8659c0 (20), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83e380/0x867ea0 (20), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x8674d0/0x85f9d0 (19), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x8674d0/0x83ef70 (19), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Entering. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x86f2e0. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_init_connection] (0x0200): Adding connection 86F2E0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_add_watch] (0x2000): 0x86fa10/0x86e040 (22), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86fa10/0x86ee70 (22), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_server_init_new_connection] (0x0200): Got a connection > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x86fc80] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86e2a0/0x86ca30 (21), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86e2a0/0x86cd90 (21), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83e380/0x8659c0 (20), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x83e380/0x867ea0 (20), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86fa10/0x86ee70 (22), R/- (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86fa10/0x86e040 (22), -/W (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86e2a0/0x86ca30 (21), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86e2a0/0x86cd90 (21), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [RegisterService] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Cancel DP ID timeout [0x86bfa0] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Added Frontend client [PAC] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86fa10/0x86ee70 (22), R/- (enabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_toggle_watch] (0x4000): 0x86fa10/0x86e040 (22), -/W (disabled) > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86DBC0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [RegisterService] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Cancel DP ID timeout [0x86e510] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Added Frontend client [SSH] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [RegisterService] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Cancel DP ID timeout [0x86fc80] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Added Frontend client [PAM] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [RegisterService] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Cancel DP ID timeout [0x83eda0] > (Wed Feb 12 10:29:53 2014) [sssd[be[miolinux.corp]]] [client_registration] (0x0100): Added Frontend client [NSS] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][miovision.corp] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): beginning to connect > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'neutral' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0400): SRV resolution of service 'IPA'. Will use DNS discovery domain 'miolinux.corp' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_ldap._tcp.miolinux.corp' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.miolinux.corp' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [request_watch_destructor] (0x0400): Deleting request watch > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolve_srv_done] (0x0400): Inserted server 'ipa1.miolinux.corp:389' for service IPA > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'resolved' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'name not resolved' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_is_address] (0x4000): [ipa1.miolinux.corp] does not look like an IP address > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ipa1.miolinux.corp' in files > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'resolving name' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ipa1.miolinux.corp' in files > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ipa1.miolinux.corp' in DNS > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [request_watch_destructor] (0x0400): Deleting request watch > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'name resolved' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 608 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.miolinux.corp' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sss_ldap_init_send] (0x4000): Using file descriptor [24] for LDAP connection. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ipa1.miolinux.corp:389/??base] with fd [24]. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87cbf0], ldap[0x8728c0] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: []. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultnamingcontext] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastusn] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87cbf0], ldap[0x8728c0] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_rootdse_done] (0x2000): Got rootdse > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 9896 (int: 9896) > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/rhel6-client.miolinux.corp, MIOLINUX.CORP, 86400) > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'name resolved' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'name resolved' > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 608 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 60 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2386] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2386] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [2386]. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0100): child [2386] finished successfully. > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] (0x0400): EOF received, client finished > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_MIOLINUX.CORP], expired on [1392305401] > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1392219901 > (Wed Feb 12 10:30:01 2014) [sssd[be[miolinux.corp]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/rhel6-client.miolinux.corp > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x880820], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miovision.corp,cn=ad,cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x880820], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8805f0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8806a0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8806a0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaIDRangeSize] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOLINUX.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOVISION.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87cf00 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8805f0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87cf00 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8805f0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87cf00 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87c950 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8805f0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87c950 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8805f0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87c950 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miolinux.corp,cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ab40 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ac60 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ab40 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ac60 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ab40 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=sdainard] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 8 > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x889870], ldap[0x8728c0] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87de50 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87df70 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87de50 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87df70 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87de50 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8805f0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8806a0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8806a0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8805f0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8806a0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8806a0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8805f0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_uid] (0x0400): No such entry > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88a880 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88a930 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88a880 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88a930 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88a880 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87dba0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88a0b0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87dba0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88a0b0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87dba0 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x897d90 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x898db0 > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x897d90 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x898db0 "ltdb_timeout" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x897d90 "ltdb_callback" > > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miovision.corp,cn=ad,cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87c5e0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaIDRangeSize] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 10 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x8806c0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x8806c0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOLINUX.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x8806c0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOVISION.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x8806c0], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f710 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f710 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f710 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x880220 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f190 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x880220 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f190 "ltdb_timeout" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x880220 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 11 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87f520], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87f520], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miolinux.corp,cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87f520], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ab20 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ac40 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ab20 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ac40 "ltdb_timeout" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ab20 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [cleanup_users] (0x4000): Cache expiration is set to 0 days > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sysdb_search_users] (0x2000): Search users with filter: (&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1392219003)(!(lastLogin=*)))) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x871fa0 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8720c0 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x871fa0 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8720c0 "ltdb_timeout" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x871fa0 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sysdb_search_users] (0x2000): No such entry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sysdb_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1392219003))) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87c950 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87fb30 > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87c950 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87fb30 "ltdb_timeout" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87c950 "ltdb_callback" > > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sysdb_search_groups] (0x2000): No such entry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at 1392222603.222795 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_update_send] (0x4000): Performing update > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_gss_tsig_update_step] (0x1000): Checking if the update is needed > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_is_address] (0x4000): [rhel6-client.miolinux.corp] does not look like an IP address > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'rhel6-client.miolinux.corp' in DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [request_watch_destructor] (0x0400): Deleting request watch > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA record of 'rhel6-client.miolinux.corp' in DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [request_watch_destructor] (0x0400): Deleting request watch > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_next] (0x0100): No more hosts databases to retry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_is_address] (0x4000): [rhel6-client.miolinux.corp] does not look like an IP address > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA record of 'rhel6-client.miolinux.corp' in DNS > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [request_watch_destructor] (0x0400): Deleting request watch > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [resolv_gethostbyname_next] (0x0100): No more hosts databases to retry > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_gss_tsig_update_check] (0x1000): Address on localhost only: 10.0.6.239 > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_gss_tsig_update_check] (0x0400): Detected IP addresses change, will perform an update > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [create_nsupdate_message] (0x0200): Creating update message for realm [MIOLINUX.CORP] and zone [miolinux.corp]. > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [create_nsupdate_message] (0x0400): -- Begin nsupdate message -- > realm MIOLINUX.CORP > zone miolinux.corp. > update delete rhel6-client.miolinux.corp. in A > send > update delete rhel6-client.miolinux.corp. in AAAA > send > update add rhel6-client.miolinux.corp. 86400 in A 10.0.6.239 > send > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [create_nsupdate_message] (0x0400): -- End nsupdate message -- > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2390] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2390] > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! > (Wed Feb 12 10:30:03 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_stdin_done] (0x4000): Sending nsupdate data complete > (Wed Feb 12 10:30:04 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [2390]. > (Wed Feb 12 10:30:04 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0100): child [2390] finished successfully. > (Wed Feb 12 10:30:04 2014) [sssd[be[miolinux.corp]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes > (Wed Feb 12 10:30:04 2014) [sssd[be[miolinux.corp]]] [ipa_dyndns_update_done] (0x0020): DNS update finished > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][miovision.corp] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 1 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 9 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87eb50 > > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f660 > > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87eb50 "ltdb_callback" > > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f660 "ltdb_timeout" > > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87eb50 "ltdb_callback" > > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [krb5_auth_send] (0x0100): No ccache file for user [sdainard at miovision.corp] found. > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 608 > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.miolinux.corp' > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2394] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2394] > (Wed Feb 12 10:30:06 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][MIOVISION] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12 > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88a7a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miovision.corp,cn=ad,cn=trusts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88a7a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaIDRangeSize] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 13 > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e8a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e8a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOLINUX.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSecondaryBaseRID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e8a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=MIOVISION.CORP_id_range,cn=ranges,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e8a0], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ee00 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88eeb0 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88eeb0 "ltdb_timeout" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88a900 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8913a0 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88a900 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8913a0 "ltdb_timeout" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88a900 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 14 > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88eb60], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88eb60], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=miolinux.corp,cn=ad,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTSecurityIdentifier] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88eb60], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x891fe0 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x892090 > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x891fe0 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x892090 "ltdb_timeout" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x891fe0 "ltdb_callback" > > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:08 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799002351] > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 15 > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x889870], ldap[0x8728c0] > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ef20 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88f040 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ef20 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88f040 "ltdb_timeout" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ef20 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ee00 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ef20 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ef20 "ltdb_timeout" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87de50 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f8c0 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87de50 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f8c0 "ltdb_timeout" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87de50 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89aae0 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89ac00 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89aae0 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89ac00 "ltdb_timeout" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89aae0 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a37d0 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89ac00 > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a37d0 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89ac00 "ltdb_timeout" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a37d0 "ltdb_callback" > > (Wed Feb 12 10:30:10 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:11 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:12 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:12 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:12 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:12 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799002369] > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 16 > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88e810], ldap[0x8728c0] > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87fd30 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87fe50 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87fd30 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87fe50 "ltdb_timeout" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87fd30 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f8a0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88f1d0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f8a0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88f1d0 "ltdb_timeout" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f8a0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e8b0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f780 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e8b0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f780 "ltdb_timeout" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e8b0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x899fb0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89a0d0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x899fb0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89a0d0 "ltdb_timeout" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x899fb0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89a0d0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88f1d0 > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89a0d0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88f1d0 "ltdb_timeout" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89a0d0 "ltdb_callback" > > (Wed Feb 12 10:30:13 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:14 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:16 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:16 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:16 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:16 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799002161] > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 17 > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x83cfd0], ldap[0x8728c0] > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f780 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87fda0 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f780 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87fda0 "ltdb_timeout" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f780 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e310 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88a7a0 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e310 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88a7a0 "ltdb_timeout" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e310 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ee00 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87fe50 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87fe50 "ltdb_timeout" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ee00 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89a8f0 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89aa10 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89a8f0 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89aa10 "ltdb_timeout" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89a8f0 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a3850 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89b050 > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a3850 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89b050 "ltdb_timeout" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a3850 "ltdb_callback" > > (Wed Feb 12 10:30:17 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:18 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:18 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:18 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:18 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:18 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799000513] > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 18 > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88f420], ldap[0x8728c0] > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e8a0 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f780 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e8a0 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f780 "ltdb_timeout" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e8a0 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e810 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88f9d0 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e810 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88f9d0 "ltdb_timeout" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e810 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83cf60 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ab40 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83cf60 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ab40 "ltdb_timeout" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83cf60 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89a9a0 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89aac0 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89a9a0 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89aac0 "ltdb_timeout" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89a9a0 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83cd00 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87e8a0 > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83cd00 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87e8a0 "ltdb_timeout" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83cd00 "ltdb_callback" > > (Wed Feb 12 10:30:20 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [krb5_child_timeout] (0x4000): timeout for child [2394] reached. > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [krb5_child_done] (0x0020): child failed (110 [Connection timed out]) > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa1.miolinux.corp' as 'not working' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa1.miolinux.corp' is 'not working' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.miolinux.corp' is 'neutral' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 608 > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.miolinux.corp' > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2398] > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2398] > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [2398]. > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0020): waitpid did not found a child with changed status. > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [2394]. > (Wed Feb 12 10:30:21 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0020): child [2394] was terminated by signal [9]. > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 868090 > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799002162] > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 19 > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x83dee0], ldap[0x8728c0] > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83cf20 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88f9d0 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83cf20 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88f9d0 "ltdb_timeout" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83cf20 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83cfa0 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ee00 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83cfa0 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ee00 "ltdb_timeout" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83cfa0 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sysdb_search_user_by_name] (0x0400): No such entry > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x83dc90 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87f780 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x83dc90 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87f780 "ltdb_timeout" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x83dc90 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89ace0 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x89ae00 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89ace0 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x89ae00 "ltdb_timeout" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89ace0 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x89ae00 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87de50 > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x89ae00 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87de50 "ltdb_timeout" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x89ae00 "ltdb_callback" > > (Wed Feb 12 10:30:22 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:25 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:26 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [2398]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0100): child [2398] finished successfully. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] (0x0400): EOF received, client finished > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][3][45]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][24]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): TGT times are [1392219022][1392219021][1392255022][1392305421]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [safe_remove_old_ccache_file] (0x0200): No old ccache, nothing to do > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [krb5_mod_ccname] (0x4000): Save ccname [FILE:/tmp/krb5cc_799001323_To6YBI] for user [sdainard at miovision.corp]. > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87e9f0 > > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87eaa0 > > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87e9f0 "ltdb_callback" > > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87eaa0 "ltdb_timeout" > > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87e9f0 "ltdb_callback" > > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:33 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8ae790 > > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8ae8f0 > > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8ae790 "ltdb_callback" > > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8ae8f0 "ltdb_timeout" > > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8ae790 "ltdb_callback" > > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:34 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x885f50 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87e670 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x885f50 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87e670 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x885f50 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_access_send] (0x0400): Performing access check for user [sdainard at miovision.corp] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x888410 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884c0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x888410 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884c0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x888410 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [sdainard at miovision.corp] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_account_expired_rhds] (0x4000): Account for user [sdainard at miovision.corp] is not locked. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [hbac_retry] (0x4000): Connection status is [online]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=rhel6-client.miolinux.corp))][cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostname] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 20 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88fe80], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [fqdn=rhel6-client.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [fqdn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverHostname] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSshPubKey] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88fe80], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [fqdn=rhel6-client.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp] using OpenLDAP deref > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][fqdn=rhel6-client.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e370], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e370], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e370], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hostgroup_info_done] (0x0200): No host groups were dereferenced > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_service_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACService)] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACService)][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 22 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sshd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ftp,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=su,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=login,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=su-l,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sudo,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sudo-i,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gdm,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gdm-password,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=kdm,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gssftp,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=crond,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=vsftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=pure-ftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=proftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_servicegroup_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACServiceGroup)] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACServiceGroup)][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 23 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87eee0], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87eee0], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=Sudo,cn=hbacservicegroups,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [member] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87eee0], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ftp,cn=hbacservicegroups,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [member] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87eee0], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=rhel6-client.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=rhel6-client.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 24 > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [ipaUniqueID=513e618e-91d7-11e3-b5df-001a4a99e68a,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaenabledflag] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [accessRuleType] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [userCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [serviceCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [sourceHostCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [hostCategory] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e670], ldap[0x8728c0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x872280 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ea10 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x872280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ea10 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x872280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [rhel6-client.miolinux.corp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb780 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8ba8a0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb780 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8ba8a0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb780 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bcbf0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bcca0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bcbf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bcca0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bcbf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bc280 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bb780 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bc280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bb780 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bc280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sshd]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bae20 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8baed0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bae20 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8baed0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bae20 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a3c60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a3d10 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a3c60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a3d10 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a3c60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [ftp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bb400 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bb400 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb400 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4120 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4120 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [su]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb400 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb400 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb400 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [login]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a39e0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a39e0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [su-l]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sudo]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb680 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bddd0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb680 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bddd0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb680 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sudo-i]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bb680 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bf820 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bb680 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bf820 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bb680 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gdm]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bcfc0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bcfc0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gdm-password]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bfc60 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [kdm]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bd860 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bfc60 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bd860 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bfc60 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bd860 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gssftp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [crond]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [vsftpd]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8d4580 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8d4580 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8d4580 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8d4580 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bddd0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8d4580 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bddd0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8d4580 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [pure-ftpd]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [proftpd]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8d5620 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8d5620 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8d5620 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a4390 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a4390 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a4390 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [Sudo]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8ba280 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872f30 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8ba280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872f30 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8ba280 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a40c0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bbcf0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a40c0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bbcf0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a40c0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [ftp]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bbcf0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a3e40 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a3ef0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a3e40 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a3ef0 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a3e40 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bbcf0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8cd770 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [513e618e-91d7-11e3-b5df-001a4a99e68a]. > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8cd770 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8cd770 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8bbcf0 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8bbe10 > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8bbe10 "ltdb_timeout" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8bbcf0 "ltdb_callback" > > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:35 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x872f30 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ea10 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x872f30 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ea10 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x872f30 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88ea10 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8861b0 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88ea10 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8861b0 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88ea10 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [hbac_eval_user_element] (0x1000): No groups for [sdainard at miovision.corp] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a3b20 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a3b20 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a3b20 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88fe50 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88fe50 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88fe50 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a38b0 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a38b0 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a38b0 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8adf00 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x886100 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8adf00 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x886100 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8adf00 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x886100 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8adf00 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x886100 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8adf00 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x886100 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_get_selinux_send] (0x2000): Connection status is [online]. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 25 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87d520], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ipaConfig,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaMigrationEnabled] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapDefault] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapOrder] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87d520], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [seeAlso] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUser] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 26 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e340], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x87e340], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8ae960 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x87e670 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8ae960 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x87e670 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8ae960 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8aefb0 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8af060 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8aefb0 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8af060 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8aefb0 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x8a6290 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8a3b90 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x8a6290 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8a3b90 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x8a6290 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=sdainard] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f660 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884e0 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884e0 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e180 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884e0 > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e180 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884e0 "ltdb_timeout" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e180 "ltdb_callback" > > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:36 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f660 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884e0 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884e0 "ltdb_timeout" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=sdainard] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x88e180 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884e0 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x88e180 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884e0 "ltdb_timeout" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x88e180 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87f660 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x8884e0 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x8884e0 "ltdb_timeout" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87f660 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 0 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2401 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 867A00 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799001323] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=miolinux,dc=corp] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=799001323)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 27 > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[0x88ef50], ldap[0x8728c0] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results. > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x87fb30 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ea10 > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x87fb30 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ea10 "ltdb_timeout" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x87fb30 "ltdb_callback" > > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory) > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x8733e0], connected[1], ops[(nil)], ldap[0x8728c0] > (Wed Feb 12 10:30:37 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x872280 > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x88ea10 > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x872280 "ltdb_callback" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x88ea10 "ltdb_timeout" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x872280 "ltdb_callback" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_CLOSE_SESSION > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x872f30 > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x872280 > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x872f30 "ltdb_callback" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x872280 "ltdb_timeout" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x872f30 "ltdb_callback" > > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 86F2E0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 2384 > (Wed Feb 12 10:30:39 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:30:43 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:43 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:43 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:30:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:30:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:30:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:31:03 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 83E740 > (Wed Feb 12 10:31:03 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:31:03 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d2f800 > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d45090 > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d2f800 "ltdb_callback" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d45090 "ltdb_timeout" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d2f800 "ltdb_callback" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 1 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 9 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d2b630 > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d2d8f0 > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d2b630 "ltdb_callback" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d2d8f0 "ltdb_timeout" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d2b630 "ltdb_callback" > > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [cc_residual_is_used] (0x0400): User [799001323] is not active > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [check_for_valid_tgt] (0x0020): krb5_cc_retrieve_cred failed. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [krb5_auth_send] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_799001323_6IUevO] and is not active and TGT is not valid. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [get_server_status] (0x1000): Status of server 'ipa1.miolinux.corp' is 'working' > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [be_resolve_server_process] (0x0200): Found address for server ipa1.miolinux.corp: [10.0.6.3] TTL 680 > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa1.miolinux.corp' > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [6389] > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [child_handler_setup] (0x2000): Signal handler set up for pid [6389] > (Wed Feb 12 10:14:53 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler] (0x0400): All data has been sent! > (Wed Feb 12 10:14:56 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1CEC6C0 > (Wed Feb 12 10:14:56 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:14:56 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler] (0x0400): EOF received, client finished > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][3][45]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][24]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): TGT times are [1392218095][1392218093][1392254095][1392304493]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [set_server_common_status] (0x0100): Marking server 'ipa1.miolinux.corp' as 'working' > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [krb5_mod_ccname] (0x4000): Save ccname [FILE:/tmp/krb5cc_799001323_yGLC3G] for user [sdainard at miovision.corp]. > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d51d10 > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d48a90 > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d51d10 "ltdb_callback" > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d48a90 "ltdb_timeout" > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d51d10 "ltdb_callback" > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d48bc0 > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5d130 > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d48bc0 "ltdb_callback" > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5d130 "ltdb_timeout" > > (Wed Feb 12 10:15:02 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d48bc0 "ltdb_callback" > > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x1000): Waiting for child [6389]. > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [child_sig_handler] (0x0100): child [6389] finished successfully. > (Wed Feb 12 10:15:03 2014) [sssd[be[miolinux.corp]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d45d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5c720 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d45d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5c720 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d45d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_access_send] (0x0400): Performing access check for user [sdainard at miovision.corp] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d51830 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d2ec70 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d51830 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d2ec70 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d51830 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [sdainard at miovision.corp] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_account_expired_rhds] (0x4000): Account for user [sdainard at miovision.corp] is not locked. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [hbac_retry] (0x4000): Connection status is [online]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=snapshot-test.miolinux.corp))][cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostname] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 22 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [fqdn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverHostname] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSshPubKey] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp] using OpenLDAP deref > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 23 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hostgroup_info_done] (0x0200): No host groups were dereferenced > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_service_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACService)] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACService)][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 24 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sshd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ftp,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=su,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=login,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=su-l,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sudo,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=sudo-i,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gdm,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gdm-password,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=kdm,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=gssftp,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=crond,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=vsftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=pure-ftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=proftpd,cn=hbacservices,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_servicegroup_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(objectClass=ipaHBACServiceGroup)] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACServiceGroup)][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 25 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=Sudo,cn=hbacservicegroups,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [member] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ftp,cn=hbacservicegroups,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [member] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=miolinux,dc=corp][2][(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=snapshot-test.miolinux.corp,cn=computers,cn=accounts,dc=miolinux,dc=corp)))][cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaenabledflag] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accessRuleType] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberService] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serviceCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHost] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sourceHostCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalHost] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 26 > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [ipaUniqueID=513e618e-91d7-11e3-b5df-001a4a99e68a,cn=hbac,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectclass] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipauniqueid] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaenabledflag] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [accessRuleType] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [userCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [serviceCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [sourceHostCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [hostCategory] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2eb30], ldap[0x1d21770] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d45d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d36550 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d45d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d36550 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d45d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Found [1] items to delete. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=snapshot-test.miolinux.corp,cn=hbac_hosts,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d68fb0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d69060 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d68fb0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d697a0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d689b0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d69060 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d68fb0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d697a0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d689b0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d697a0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [snapshot-test.miolinux.corp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d68f80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d68f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d68f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d59e00 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d59e00 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d68f80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d689b0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d68f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d689b0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d68f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Found [15] items to delete. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=su-l,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7a020 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7a0d0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7a020 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7aae0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7ab90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7a0d0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7a020 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7aae0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7ab90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7aae0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=ftp,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d79dc0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7b0c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d79dc0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7e210 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d76360 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7b0c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d79dc0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7e210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d76360 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7e210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=vsftpd,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7af70 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7a060 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7af70 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7a790 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d76410 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7a060 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7af70 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7a790 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d76410 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7a790 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=pure-ftpd,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7edd0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7ebc0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7edd0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d76610 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d79c90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7ebc0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7edd0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d76610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d79c90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d76610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=login,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d815a0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7e0c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d815a0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d54210 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7c2e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7e0c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d815a0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d54210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7c2e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d54210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=kdm,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d79aa0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d54210 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d79aa0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7a6f0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7c2e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d54210 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d79aa0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7a6f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7c2e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7a6f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=su,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d86610 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d79c90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d86610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d81780 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7b0c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d79c90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d86610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d81780 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7b0c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d81780 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=sudo-i,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d86610 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d79c90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d86610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d81150 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d79c90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d86610 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d81150 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d81150 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=sshd,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7e210 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d76610 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7e210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d82dd0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d76610 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7e210 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d82dd0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=sudo,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d817e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7e0c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d817e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8b300 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d76610 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7e0c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d817e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8b300 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d76610 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8b300 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=gssftp,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d81150 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d81150 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d79c90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d88be0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d81150 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d79c90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d88be0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d79c90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=crond,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8bc90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8bc90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8e740 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d82fa0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8bc90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8e740 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d82fa0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8e740 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=gdm-password,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8b8f0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d8bc90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8b8f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d88be0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d8bc90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8b8f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d88be0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=gdm,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d82fa0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8e740 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d909e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d82fa0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8e740 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d909e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8e740 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=proftpd,cn=hbac_services,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d82fa0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d909e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d82fa0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d91220 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d91720 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d909e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d82fa0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d91220 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d91720 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d91220 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sshd]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d909e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d909e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d909e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d47b10 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d47b10 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d47b10 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [ftp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d1cca0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d909e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d909e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [su]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [login]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [su-l]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sudo]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d77f30 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d77f30 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d77f30 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d77f30 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d77f30 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [sudo-i]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d78c50 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d77f30 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d78c50 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d77f30 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d78c50 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d73d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gdm]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d73d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d73d80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gdm-password]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7c9f0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d68dc0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7c9f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d68dc0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7c9f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [kdm]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d919f0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d919f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d919f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [gssftp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d683b0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d683b0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [crond]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7abe0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [vsftpd]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7abe0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d877e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [pure-ftpd]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7abe0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d912c0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7abe0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7abe0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [proftpd]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d7abe0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d7abe0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d912c0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d877e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d877e0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d912c0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d92760 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d92a90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d92760 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d92a90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d92760 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Found [2] items to delete. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=Sudo,cn=hbac_servicegroups,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d8ead0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d8eb80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d8ead0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d53970 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d90a90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d8eb80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d8ead0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d53970 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d90a90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d53970 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=ftp,cn=hbac_servicegroups,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d81900 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d8e8a0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d81900 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d54280 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d538d0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d8e8a0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d81900 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d54280 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d538d0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d54280 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [Sudo]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d54280 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d92a90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d54280 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d92a90 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d54280 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d767f0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d54550 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d767f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d54550 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d767f0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [ftp]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d53f80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d7de50 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d53f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d7de50 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d53f80 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d91c90 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d91ed0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d91c90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d91ed0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d91c90 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d91ed0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d53f80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d91ed0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d53f80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d91ed0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Found [1] items to delete. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [name=513e618e-91d7-11e3-b5df-001a4a99e68a,cn=hbac_rules,cn=custom,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d6f590 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d8ead0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d6f590 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d542e0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d8bc70 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d8ead0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d6f590 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d542e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d8bc70 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d542e0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_save_list] (0x4000): Object name: [513e618e-91d7-11e3-b5df-001a4a99e68a]. > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d68ea0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d91ed0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d68ea0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d91ed0 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d68ea0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d68ea0 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d45d80 > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d68ea0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d45d80 "ltdb_timeout" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d68ea0 "ltdb_callback" > > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:04 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d1cca0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d36550 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_get_category] (0x0200): Category is set to 'all'. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d47e40 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d47e40 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [hbac_eval_user_element] (0x1000): No groups for [sdainard at miovision.corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d50af0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5ccd0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d50af0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5ccd0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d50af0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d1cca0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5be00 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5be00 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d1cca0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5ccd0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5ccd0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d1cca0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[(nil)], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d514f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d47e40 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d514f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d47e40 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d514f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d514f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d5b720 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d514f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d5b720 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d514f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_selinux_send] (0x2000): Connection status is [online]. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 27 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=ipaConfig,cn=etc,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaMigrationEnabled] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapDefault] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapOrder] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d49140], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [seeAlso] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUser] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 28 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d45a90], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d45a90], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d47e40 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d4a1f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d47e40 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d4a1f0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d47e40 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Found [1] items to delete. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_recursive] (0x4000): Trying to delete [cn=selinux,cn=miolinux.corp,cn=sysdb]. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d52360 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d52410 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d52360 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d52560 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d53c20 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d52410 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d52360 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d52560 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d53c20 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d52560 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d522c0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d52370 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d522c0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d52370 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d522c0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d461c0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d4a1f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d461c0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d4a1f0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d461c0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler_callback] (0x0100): Sent result [0][miovision.corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[(nil)], ldap[0x1d21770] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D16600 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=sdainard] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d4a1f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d4a1f0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d52d80 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d52d80 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d4a1f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d1cca0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d4a1f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d1cca0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d4a1f0 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D16600 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=sdainard] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d52d80 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d52d80 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d4a1f0 > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d4a1f0 "ltdb_timeout" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 0 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6391 > (Wed Feb 12 10:15:05 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1CEC6C0 > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D16600 > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=799001323] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=miolinux,dc=corp] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=799001323)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=miolinux,dc=corp]. > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 29 > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[0x1d2e4d0], ldap[0x1d21770] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results. > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36260 > > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d2f800 > > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36260 "ltdb_callback" > > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d2f800 "ltdb_timeout" > > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36260 "ltdb_callback" > > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory) > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: sh[0x1d21d90], connected[1], ops[(nil)], ldap[0x1d21770] > (Wed Feb 12 10:15:06 2014) [sssd[be[miolinux.corp]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Feb 12 10:15:16 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1CEC6C0 > (Wed Feb 12 10:15:16 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:16 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:15:26 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1CEC6C0 > (Wed Feb 12 10:15:26 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:26 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d36550 > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d1cca0 > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d1cca0 "ltdb_timeout" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d36550 "ltdb_callback" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_CLOSE_SESSION > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_get_account_info] (0x0100): Got request for [3][1][name=sdainard] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1d20e80 > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1d2f800 > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Running timer event 0x1d20e80 "ltdb_callback" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Destroying timer event 0x1d2f800 "ltdb_timeout" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ldb] (0x4000): Ending timer event 0x1d20e80 "ltdb_callback" > > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the cache. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): dbus conn: 1D1BC00 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Got request with the following data > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): command: PAM_SETCRED > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): domain: miovision.corp > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): user: sdainard at miovision.corp > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): service: sshd > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): tty: ssh > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): ruser: > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): rhost: localhost > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok type: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): authtok size: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok type: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): newauthtok size: 0 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): priv: 1 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [pam_print_data] (0x0100): cli_pid: 6386 > (Wed Feb 12 10:15:28 2014) [sssd[be[miolinux.corp]]] [be_pam_handler] (0x0100): Sending result [0][miovision.corp] From dpal at redhat.com Wed Feb 12 18:08:38 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 13:08:38 -0500 Subject: [Freeipa-users] Recommend version of Samba for a CentOS 6.5 IPA client? In-Reply-To: References: Message-ID: <52FBB8A6.7070302@redhat.com> On 02/11/2014 04:22 PM, Mark Gardner wrote: > Before I go installing Samba for File Sharing. I wanted to make sure > I was installing the correct version of Samba without conflicting with > the Linux server being an IPA client. > > Currently installed sambaX packages: > > samba-client.x86_64 3.6.9-167.el6_5 > @updates > samba-common.x86_64 3.6.9-167.el6_5 > @updates > samba-winbind.x86_64 3.6.9-167.el6_5 > @updates > samba-winbind-clients.x86_64 3.6.9-167.el6_5 > @updates > samba4-libs.x86_64 4.0.0-60.el6_5.rc4 > @updates > > So do I uninstall samba 3.6.9 and install the appropriate samba4 > packages or just yum install samba? > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I do not think things would work nicely in the current state of affairs. You can try but I suspect there will be conflicts. We are slowly working on this but it is not ready. I suggest you try Samba FS on a different system to avoid collisions and complications. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 12 18:10:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 13:10:51 -0500 Subject: [Freeipa-users] trouble creating a replica in the cloud In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> Message-ID: <52FBB92B.4070606@redhat.com> On 02/11/2014 05:02 PM, Todd Maugh wrote: > Hey Guys, > > So I have my master and replica up in my datacenter. > > I have a client, I have a winsync agreement, I have a password sync. > > It's working lovely. > > So Now I have spun up an AWS instance of redh hat 6.5 (same as my > master and first replica) > > I run the ipa replica and it fails > > > ipa-replica-install --setup-ca --setup-dns --no-forwarders > /var/lib/ipa/replica-info-se-idm-03.boingo.com.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'se-idm-01.boingo.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 > PKI-CA: Directory Service port (7389): 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 BOINGO.COM password: > > Execute check on remote master > Check connection from master to remote replica 'se-idm-03.boingo.com': > 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 > PKI-CA: Directory Service port (7389): OK > > Connection from master to replica is OK. > > Connection check OK > 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 for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > ipa : CRITICAL failed to create ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3' > returned non-zero exit status 1 > [3/3]: restarting directory server > ipa : CRITICAL Failed to restart the directory server. See the > installation log for details. > Done configuring directory server for the CA (pkids). > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > Can't contact LDAP server > > > I check the log file and this is what I get > > 2014-02-11T19:55:48Z DEBUG calling setup-ds.pl > 2014-02-11T19:57:53Z DEBUG args=/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmpo9ROF3 > 2014-02-11T19:57:53Z DEBUG stdout=[11/Feb/2014:14:57:53 -0500] > createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: > Netscape Portable Runtime error -5966 (Access Denied.) > [11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All > Interfaces port 7389 failed: Netscape Portable Runtime error -5966 > (Access Denied.) > [14/02/11:14:57:53] - [Setup] Info Could not start the directory > server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. > The last line from the error log was '[11/Feb/2014:14:57:53 -0500] create > prlistensockets - PR_Bind() on All Interfaces port 7389 failed: > Netscape Portable Runtime error -5966 (Access Denied.) > '. Error: Unknown error 256 > Could not start the directory server using command > '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the > error log was '[11/Feb/2014:14:57:53 -0500] createprlistensockets - > PR_Bind() on All > Interfaces port 7389 failed: Netscape Portable Runtime error -5966 > (Access Denied.) > '. Error: Unknown error 256 > [14/02/11:14:57:53] - [Setup] Fatal Error: Could not create directory > server instance 'PKI-IPA'. > Error: Could not create directory server instance 'PKI-IPA'. > [14/02/11:14:57:53] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > > > Please help > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Bind failed. This usually happens when the system has an identity crisis and tries to bind to the interface that is not there. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Wed Feb 12 18:10:57 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 10:10:57 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FB349B.6020901@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> Message-ID: <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e? I seem to get stuck with making the replica with the "--setup-ca" option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install.? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek wrote: On 11.2.2014 23:53, Shree wrote: > Following ports are opened between the > 1) Between the master and the replica (bi directional) > 2) client machine and the ipa replica (unidirectional). > When the replica was up it worked fine as far as syncing was concerned. > >? 80 tcp >? 443 tcp >? 389 tcp >? 636 tcp >? 88 tcp >? 464 tcp >? 88 udp >? 464 udp >? 123 udp > > Shreeraj > ---------------------------------------------------------------------------------------- > > Change is the only Constant ! > > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal wrote: > > On 02/11/2014 05:05 PM, Shree wrote: > Dimitri >> Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) > Please republish it on the list. > Do not reply to me directly. > > Did you set your first server with the CA? Does all ports that need >? ? ? to be open in the firewall between primary or server are actually >? ? ? open? > > > >> >> What I have done so far is uninstalled the replica and tried to install it again using the "--setup-ca" option. Previously I had failures and when I removed the "--setup-ca" option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. >> >> >> 1)The workaround helped me go forward a bit but I got stuck at this point see below >> =========== >>? ? [1/3]: creating directory server user >>? ? [2/3]: creating directory server instance >>? ? [3/3]: restarting directory server >> Done configuring directory server for the CA (pkids). >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >>? ? [1/17]: creating certificate server user >>? ? [2/17]: creating pki-ca instance >>? ? [3/17]: configuring certificate server instance >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >> =========== >> 2) No we do not use IPA for a DNS server. >> >> >> 3)The reason for this could be that I had installed the replica without the "--setup-ca". >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> >> Change is the only Constant ! >> >> >> >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal wrote: >> >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>> Shree wrote: >>>> Lukas >>>> Perhaps I should explain the design a bit and >? ? ? ? ? ? ? ? ? see if FreeIPA even >>>> supports this.Our replica is in a separate >? ? ? ? ? ? ? ? ? network and all the >>>> appropriate ports are opened between the master >? ? ? ? ? ? ? ? ? and the replica. The >>>> "replica" got created successfully and is in >? ? ? ? ? ? ? ? ? sync with the master >>>> (except the CA services which I mentioned >? ? ? ? ? ? ? ? ? earlier) >>>> Now,when I try to run ipa-client-install on >? ? ? ? ? ? ? ? ? hosts in the new network >>>> using the replica, it complains that about >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>>> realm". >>>> I am wondering it my hosts in the new network >? ? ? ? ? ? ? ? ? are trying to access the >>>> "master" for certificates since the replica >? ? ? ? ? ? ? ? ? does not have any CA >>>> services running? I couldn't find any obvious >? ? ? ? ? ? ? ? ? proof of this even running >>>> the install in a debug mode. Do I need to open >? ? ? ? ? ? ? ? ? ports between the new >>>> hosts and the master for CA services? >>>> At this point I cannot disable or? move the >? ? ? ? ? ? ? ? ? master, it needs to function >>>> in its location but I need >>> >>> No, the clients don't directly talk to the CA. >>> >>> You'd need to look in >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>> was found and we were trying to use. If you have >? ? ? ? ? ? ? ? ? SRV records for both >>> but we try to contact the hidden master this will >? ? ? ? ? ? ? ? ? happen. You can try >>> specifying the server on the command-line with >? ? ? ? ? ? ? ? ? --server but this will >>> be hardcoding things and make it less flexible >? ? ? ? ? ? ? ? ? later. >>> >>> rob >>> >>>> Shreeraj >>>> >? ? ? ? ? ? ? ? ? ---------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> Change is the only Constant ! >>>> >>>> >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >? ? ? ? ? ? ? ? ? Slebodnik >>>> wrote: >>>> On (06/02/14 18:33), Shree wrote: >>>> >>>>> First of all, the ipa-replica-install did >? ? ? ? ? ? ? ? ? not allow me to use >>>> the --setup-ca >>>>> option complaining that a cert already >? ? ? ? ? ? ? ? ? exists, replicate creation was >>>>> successful after I skipped the option. >>>>> Seems like the replica is one except >>>>> 1) There is no CA Service running on the >? ? ? ? ? ? ? ? ? replica (which I guess is >>>> expected) >>>>> and >>>>> 2) I am unable to run ipa-client-install >? ? ? ? ? ? ? ? ? successfully on any clients >>>> using >>>>> the replica. (I don't have the option of >? ? ? ? ? ? ? ? ? using the primary master as >>>> it is >>>>> configured in a segregated environment. >? ? ? ? ? ? ? ? ? Only the master and replica >>>> are >>>>> allowed to sync. >>>>> Debug shows it fails at >>>>> >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >? ? ? ? ? ? ? ? ? contact any KDC for realm >>>> 'mydomainname.com' while getting initial >? ? ? ? ? ? ? ? ? credentials >>>> >>>>> >>>>> >>>> >>>> I was not able to install replica witch CA on >? ? ? ? ? ? ? ? ? fedora 20, >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>> >>>> Guys from dogtag found a workaround >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>> >>>> Does it work for you? >>>> >>>> LS >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> What server provides DNS capabilities to the clients? >> Do you use IPA DNS or some other DNS? >> Clients seem to not be able to see replica KDC and try >? ? ? ? ? ? ? ? ? to access hidden >> master but they can know about this master only via DNS. Shree, make sure that command $ dig -t SRV _kerberos._udp.ipa.example on the client returns both IPA servers (in ANSWER section). -- Petr^2 Spacek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 12 18:30:59 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 13:30:59 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB8577.3010601@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> Message-ID: <52FBBDE3.4090102@redhat.com> On 02/12/2014 09:30 AM, Tamas Papp wrote: > On 02/12/2014 03:04 PM, Petr Spacek wrote: >> On 12.2.2014 15:01, Tamas Papp wrote: >>> On 02/12/2014 01:34 PM, Alexander Bokovoy wrote: >>>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>>> On 02/12/2014 01:07 PM, Alexander Bokovoy wrote: >>>>>> On Wed, 12 Feb 2014, Tamas Papp wrote: >>>>>>> hi All, >>>>>>> >>>>>>> $ ldapsearch -x -D uid=USER,cn=users,cn=compat,dc=foo -h >>>>>>> localhost -w >>>>>>> `cat pw` >>>>>>> ldap_bind: Referral (10) >>>>>>> referrals: >>>>>>> ldap:///uid=USER,cn=users,cn=accounts,dc=foo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 fd=79 slot=79 connection >>>>>>> from >>>>>>> ::1 to ::1 >>>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 BIND >>>>>>> dn="uid=USER,cn=users,cn=compat,dc=foo" method=128 version=3 >>>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=0 RESULT err=10 tag=97 >>>>>>> nentries=0 etime=0 >>>>>>> [12/Feb/2014:12:54:15 +0100] conn=25363 op=-1 fd=79 closed - B1 >>>>>>> >>>>>>> >>>>>>> System is Centos 6.5 and ldap was migrated from IPA 3.3 (Fedora 20). >>>>>>> Non-compat authentication works fine and authorization against >>>>>>> compat is >>>>>>> also fine. >>>>>>> >>>>>>> >>>>>>> What is err=10? >>>>>> slapi-nis module in RHEL 6.x (and CentOS) does not support bind >>>>>> against >>>>>> compat tree. We added this feature only in Fedora 20 (and RHEL 7 >>>>>> beta). >>>>>> >>>>>> In older versions slapi-nis issues LDAP referral to the original LDAP >>>>>> entry with the hope that an LDAP client would follow it and perform a >>>>>> bind against the referral. >>>>>> >>>>>> Unfortunately, there is virtually no client software that supports >>>>>> the >>>>>> referral on bind operation. >>>>>> >>>>>> In short, you cannot do LDAP bind against compat tree in RHEL before >>>>>> 7.0. >>>>> I forgot to mention, the client would be Ubuntu 12.04 and it >>>>> works/worked with IPA 3.3 and F20. >>>> It worked with IPA 3.3 because of what I wrote above -- I implemented >>>> LDAP BIND authentication in slapi-nis in IPA 3.3 instead of issuing >>>> LDAP >>>> referral to the original entry's DN. >>>> >>>>> If I understand correctly, you're referring to the client side, are >>>>> you? >>>> No. >>>> >>>>> Or it is true for the server side as well? >>>> It is purely server-side issue. slapi-nis< 0.47.5 does not support >>>> proper authentication against compat tree that LDAP clients understand. >>> Actually I'd like to authenticate shell users on Ubuntu. >>> >>> For the records I figured out, that switching from nscd to nslcd did the >>> trick. >> BTW why you don't use SSSD? It is packaged for Ubuntu for sure. NSCD >> is ... obsolete. SSSD has some very nice features like off-line cache >> etc. > I don't know it. > After a quick look I wasn't able to set it up correctly, 'id USER' > didn't connected to it's socket like with nscd/nlscd, however > nsswitch.conf was configured. > Maybe with the upcoming 14.04 or do you have a working howto for 12.04? Please check SSSD web site for guidelines and if you have any questions do not hesitate to ask on the sssd-users list. SSSD is the best you can get nowadays for the connection of the client systems to the central identity stores. If you plan to use it with IPA you ho not need to configure sssd manually. ipa-client-install will do the trick. Just install ipa-client package and run the command. > > > Thx, > tamas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Feb 12 18:32:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Feb 2014 13:32:14 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> Message-ID: <52FBBE2E.9020904@redhat.com> Shree wrote: > Peter > Actually I mentioned earlier that my clients are in a separate VLAN and > cannot access the master. We have made provisions for the master and the > replica to sync by opening the needed ports in the firewall. We have > also opened up ports between the clients and the replica. I have tested > the connectivity for these ports. > Perhaps you can tell me if what I am trying to achieve is even possible? > i.e > I seem to get stuck with making the replica with the "--setup-ca" > option. Wthout that option I am able to create a replica and have it in > sync with the master. However my ipa-client-install fails from clients > as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek > wrote: > On 11.2.2014 23:53, Shree wrote: > > > Following ports are opened between the > > 1) Between the master and the replica (bi directional) > > 2) client machine and the ipa replica (unidirectional). > > When the replica was up it worked fine as far as syncing was concerned. > > > > 80 tcp > > 443 tcp > > 389 tcp > > 636 tcp > > 88 tcp > > 464 tcp > > 88 udp > > 464 udp > > 123 udp > > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > Change is the only Constant ! > > > > > > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > wrote: > > > > On 02/11/2014 05:05 PM, Shree wrote: > > Dimitri > >> Sorry some the mail landed in my SPAM folder. Let answer your > questions (thanks for your help man) > > Please republish it on the list. > > Do not reply to me directly. > > > > Did you set your first server with the CA? Does all ports that need > > to be open in the firewall between primary or server are actually > > open? > > > > > > > >> > >> What I have done so far is uninstalled the replica and tried to > install it again using the "--setup-ca" option. Previously I had > failures and when I removed the "--setup-ca" option the installation > succeeded (in a way). I understand now that I really need to fix the CA > installation errors first. > >> > >> > >> 1)The workaround helped me go forward a bit but I got stuck at this > point see below > >> =========== > >> [1/3]: creating directory server user > >> [2/3]: creating directory server instance > >> [3/3]: restarting directory server > >> Done configuring directory server for the CA (pkids). > >> ipa : ERROR certmonger failed starting to track > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit > status 1 > >> Configuring certificate server (pki-cad): Estimated time 3 minutes > 30 seconds > >> [1/17]: creating certificate server user > >> [2/17]: creating pki-ca instance > >> [3/17]: configuring certificate server instance > >> ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - > >> =========== > >> 2) No we do not use IPA for a DNS server. > >> > >> > >> 3)The reason for this could be that I had installed the replica > without the "--setup-ca". > >> > >> Shreeraj > >> > ---------------------------------------------------------------------------------------- > >> > >> > >> > >> Change is the only Constant ! > >> > >> > >> > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > wrote: > >> > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: > >>> Shree wrote: > >>>> Lukas > >>>> Perhaps I should explain the design a bit and > > see if FreeIPA even > >>>> supports this.Our replica is in a separate > > network and all the > >>>> appropriate ports are opened between the master > > and the replica. The > >>>> "replica" got created successfully and is in > > sync with the master > >>>> (except the CA services which I mentioned > > earlier) > >>>> Now,when I try to run ipa-client-install on > > hosts in the new network > >>>> using the replica, it complains that about > > "Cannot contact any KDC for > >>>> realm". > >>>> I am wondering it my hosts in the new network > > are trying to access the > >>>> "master" for certificates since the replica > > does not have any CA > >>>> services running? I couldn't find any obvious > > proof of this even running > >>>> the install in a debug mode. Do I need to open > > ports between the new > >>>> hosts and the master for CA services? > >>>> At this point I cannot disable or move the > > master, it needs to function > >>>> in its location but I need > >>> > >>> No, the clients don't directly talk to the CA. > >>> > >>> You'd need to look in > > /var/log/ipaclient-install.log to see what KDC > >>> was found and we were trying to use. If you have > > SRV records for both > >>> but we try to contact the hidden master this will > > happen. You can try > >>> specifying the server on the command-line with > > --server but this will > >>> be hardcoding things and make it less flexible > > later. > >>> > >>> rob > >>> > >>>> Shreeraj > >>>> > > > ---------------------------------------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> Change is the only Constant ! > >>>> > >>>> > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas > > Slebodnik > >>>> > wrote: > >>>> On (06/02/14 18:33), Shree wrote: > >>>> > >>>>> First of all, the ipa-replica-install did > > not allow me to use > >>>> the --setup-ca > >>>>> option complaining that a cert already > > exists, replicate creation was > >>>>> successful after I skipped the option. > >>>>> Seems like the replica is one except > >>>>> 1) There is no CA Service running on the > > replica (which I guess is > >>>> expected) > >>>>> and > >>>>> 2) I am unable to run ipa-client-install > > successfully on any clients > >>>> using > >>>>> the replica. (I don't have the option of > > using the primary master as > >>>> it is > >>>>> configured in a segregated environment. > > Only the master and replica > >>>> are > >>>>> allowed to sync. > >>>>> Debug shows it fails at > >>>>> > >>>>> ipa : DEBUG stderr=kinit: Cannot > > contact any KDC for realm > >>>> 'mydomainname.com' while getting initial > > credentials > >>>> > >>>>> > >>>>> > >>>> > >>>> I was not able to install replica witch CA on > > fedora 20, > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 > >>>> > >>>> Guys from dogtag found a workaround > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 > >>>> > >>>> Does it work for you? > >>>> > >>>> LS > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Freeipa-users mailing list > >>>> Freeipa-users at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> What server provides DNS capabilities to the clients? > >> Do you use IPA DNS or some other DNS? > >> Clients seem to not be able to see replica KDC and try > > to access hidden > >> master but they can know about this master only via DNS. > > > Shree, make sure that command > $ dig -t SRV _kerberos._udp.ipa.example > on the client returns both IPA servers (in ANSWER section). > > -- > Petr^2 Spacek > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Wed Feb 12 18:36:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Feb 2014 13:36:15 -0500 Subject: [Freeipa-users] trouble creating a replica in the cloud In-Reply-To: <52FBB92B.4070606@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> <52FBB92B.4070606@redhat.com> Message-ID: <52FBBF1F.4060106@redhat.com> Dmitri Pal wrote: > On 02/11/2014 05:02 PM, Todd Maugh wrote: >> Hey Guys, >> >> So I have my master and replica up in my datacenter. >> >> I have a client, I have a winsync agreement, I have a password sync. >> >> It's working lovely. >> >> So Now I have spun up an AWS instance of redh hat 6.5 (same as my >> master and first replica) >> >> I run the ipa replica and it fails >> >> >> ipa-replica-install --setup-ca --setup-dns --no-forwarders >> /var/lib/ipa/replica-info-se-idm-03.boingo.com.gpg >> Directory Manager (existing master) password: >> >> Run connection check to master >> Check connection from replica to remote master 'se-idm-01.boingo.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 >> PKI-CA: Directory Service port (7389): 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 BOINGO.COM password: >> >> Execute check on remote master >> Check connection from master to remote replica 'se-idm-03.boingo.com': >> 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 >> PKI-CA: Directory Service port (7389): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> 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 for the CA (pkids): Estimated time 30 seconds >> [1/3]: creating directory server user >> [2/3]: creating directory server instance >> ipa : CRITICAL failed to create ds instance Command >> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3' >> returned non-zero exit status 1 >> [3/3]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server. See the >> installation log for details. >> Done configuring directory server for the CA (pkids). >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> Can't contact LDAP server >> >> >> I check the log file and this is what I get >> >> 2014-02-11T19:55:48Z DEBUG calling setup-ds.pl >> 2014-02-11T19:57:53Z DEBUG args=/usr/sbin/setup-ds.pl --silent >> --logfile - -f /tmp/tmpo9ROF3 >> 2014-02-11T19:57:53Z DEBUG stdout=[11/Feb/2014:14:57:53 -0500] >> createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: >> Netscape Portable Runtime error -5966 (Access Denied.) >> [11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All >> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >> (Access Denied.) >> [14/02/11:14:57:53] - [Setup] Info Could not start the directory >> server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. >> The last line from the error log was '[11/Feb/2014:14:57:53 -0500] create >> prlistensockets - PR_Bind() on All Interfaces port 7389 failed: >> Netscape Portable Runtime error -5966 (Access Denied.) >> '. Error: Unknown error 256 >> Could not start the directory server using command >> '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the >> error log was '[11/Feb/2014:14:57:53 -0500] createprlistensockets - >> PR_Bind() on All >> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >> (Access Denied.) >> '. Error: Unknown error 256 >> [14/02/11:14:57:53] - [Setup] Fatal Error: Could not create directory >> server instance 'PKI-IPA'. >> Error: Could not create directory server instance 'PKI-IPA'. >> [14/02/11:14:57:53] - [Setup] Fatal Exiting . . . >> Log file is '-' >> >> Exiting . . . >> Log file is '-' >> >> >> >> >> Please help >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Bind failed. This usually happens when the system has an identity crisis > and tries to bind to the interface that is not there. Access Denied is a bit unexpected though it may have to do with the AWS network config. Any SELinux errors or anything in /var/log/messages? Running IPA in AWS is a bit strange because of the dynamic nature of AWS. Have you seen http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html rob From shreerajkarulkar at yahoo.com Wed Feb 12 18:40:03 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 10:40:03 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBBE2E.9020904@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> Message-ID: <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> OK I thought CA is a part of IPA ? Below is from my master IPA server [root at ldap ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root at ldap ~]# I can certainly send you a log if needed. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden wrote: Shree wrote: > Peter > Actually I mentioned earlier that my clients are in a separate VLAN and > cannot access the master. We have made provisions for the master and the > replica to sync by opening the needed ports in the firewall. We have > also opened up ports between the clients and the replica. I have tested > the connectivity for these ports. > Perhaps you can tell me if what I am trying to achieve is even possible? > i.e > I seem to get stuck with making the replica with the "--setup-ca" > option. Wthout that option I am able to create a replica and have it in > sync with the master. However my ipa-client-install fails from clients > as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek > wrote: > On 11.2.2014 23:53, Shree wrote: > >? > Following ports are opened between the >? > 1) Between the master and the replica (bi directional) >? > 2) client machine and the ipa replica (unidirectional). >? > When the replica was up it worked fine as far as syncing was concerned. >? > >? >? 80 tcp >? >? 443 tcp >? >? 389 tcp >? >? 636 tcp >? >? 88 tcp >? >? 464 tcp >? >? 88 udp >? >? 464 udp >? >? 123 udp >? > >? > Shreeraj >? > > ---------------------------------------------------------------------------------------- >? > >? > Change is the only Constant ! >? > >? > >? > >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > wrote: >? > >? > On 02/11/2014 05:05 PM, Shree wrote: >? > Dimitri >? >> Sorry some the mail landed in my SPAM folder. Let answer your > questions (thanks for your help man) >? > Please republish it on the list. >? > Do not reply to me directly. >? > >? > Did you set your first server with the CA? Does all ports that need >? >? ? ? to be open in the firewall between primary or server are actually >? >? ? ? open? >? > >? > >? > >? >> >? >> What I have done so far is uninstalled the replica and tried to > install it again using the "--setup-ca" option. Previously I had > failures and when I removed the "--setup-ca" option the installation > succeeded (in a way). I understand now that I really need to fix the CA > installation errors first. >? >> >? >> >? >> 1)The workaround helped me go forward a bit but I got stuck at this > point see below >? >> =========== >? >>? ? [1/3]: creating directory server user >? >>? ? [2/3]: creating directory server instance >? >>? ? [3/3]: restarting directory server >? >> Done configuring directory server for the CA (pkids). >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit > status 1 >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes > 30 seconds >? >>? ? [1/17]: creating certificate server user >? >>? ? [2/17]: creating pki-ca instance >? >>? ? [3/17]: configuring certificate server instance >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >? >> =========== >? >> 2) No we do not use IPA for a DNS server. >? >> >? >> >? >> 3)The reason for this could be that I had installed the replica > without the "--setup-ca". >? >> >? >> Shreeraj >? >> > ---------------------------------------------------------------------------------------- >? >> >? >> >? >> >? >> Change is the only Constant ! >? >> >? >> >? >> >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > wrote: >? >> >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >? >>> Shree wrote: >? >>>> Lukas >? >>>> Perhaps I should explain the design a bit and >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >? >>>> supports this.Our replica is in a separate >? >? ? ? ? ? ? ? ? ? network and all the >? >>>> appropriate ports are opened between the master >? >? ? ? ? ? ? ? ? ? and the replica. The >? >>>> "replica" got created successfully and is in >? >? ? ? ? ? ? ? ? ? sync with the master >? >>>> (except the CA services which I mentioned >? >? ? ? ? ? ? ? ? ? earlier) >? >>>> Now,when I try to run ipa-client-install on >? >? ? ? ? ? ? ? ? ? hosts in the new network >? >>>> using the replica, it complains that about >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >? >>>> realm". >? >>>> I am wondering it my hosts in the new network >? >? ? ? ? ? ? ? ? ? are trying to access the >? >>>> "master" for certificates since the replica >? >? ? ? ? ? ? ? ? ? does not have any CA >? >>>> services running? I couldn't find any obvious >? >? ? ? ? ? ? ? ? ? proof of this even running >? >>>> the install in a debug mode. Do I need to open >? >? ? ? ? ? ? ? ? ? ports between the new >? >>>> hosts and the master for CA services? >? >>>> At this point I cannot disable or? move the >? >? ? ? ? ? ? ? ? ? master, it needs to function >? >>>> in its location but I need >? >>> >? >>> No, the clients don't directly talk to the CA. >? >>> >? >>> You'd need to look in >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >? >>> was found and we were trying to use. If you have >? >? ? ? ? ? ? ? ? ? SRV records for both >? >>> but we try to contact the hidden master this will >? >? ? ? ? ? ? ? ? ? happen. You can try >? >>> specifying the server on the command-line with >? >? ? ? ? ? ? ? ? ? --server but this will >? >>> be hardcoding things and make it less flexible >? >? ? ? ? ? ? ? ? ? later. >? >>> >? >>> rob >? >>> >? >>>> Shreeraj >? >>>> >? > > ---------------------------------------------------------------------------------------- >? >>>> >? >>>> >? >>>> >? >>>> Change is the only Constant ! >? >>>> >? >>>> >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >? >? ? ? ? ? ? ? ? ? Slebodnik >? >>>> > wrote: >? >>>> On (06/02/14 18:33), Shree wrote: >? >>>> >? >>>>> First of all, the ipa-replica-install did >? >? ? ? ? ? ? ? ? ? not allow me to use >? >>>> the --setup-ca >? >>>>> option complaining that a cert already >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >? >>>>> successful after I skipped the option. >? >>>>> Seems like the replica is one except >? >>>>> 1) There is no CA Service running on the >? >? ? ? ? ? ? ? ? ? replica (which I guess is >? >>>> expected) >? >>>>> and >? >>>>> 2) I am unable to run ipa-client-install >? >? ? ? ? ? ? ? ? ? successfully on any clients >? >>>> using >? >>>>> the replica. (I don't have the option of >? >? ? ? ? ? ? ? ? ? using the primary master as >? >>>> it is >? >>>>> configured in a segregated environment. >? >? ? ? ? ? ? ? ? ? Only the master and replica >? >>>> are >? >>>>> allowed to sync. >? >>>>> Debug shows it fails at >? >>>>> >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >? >>>> 'mydomainname.com' while getting initial >? >? ? ? ? ? ? ? ? ? credentials >? >>>> >? >>>>> >? >>>>> >? >>>> >? >>>> I was not able to install replica witch CA on >? >? ? ? ? ? ? ? ? ? fedora 20, >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >? >>>> >? >>>> Guys from dogtag found a workaround >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >? >>>> >? >>>> Does it work for you? >? >>>> >? >>>> LS >? >>>> >? >>>> >? >>>> >? >>>> >? >>>> >? >>>> _______________________________________________ >? >>>> Freeipa-users mailing list >? >>>> Freeipa-users at redhat.com >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >>>> >? >>> >? >>> _______________________________________________ >? >>> Freeipa-users mailing list >? >>> Freeipa-users at redhat.com >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >> >? >> What server provides DNS capabilities to the clients? >? >> Do you use IPA DNS or some other DNS? >? >> Clients seem to not be able to see replica KDC and try >? >? ? ? ? ? ? ? ? ? to access hidden >? >> master but they can know about this master only via DNS. > > > Shree, make sure that command > $ dig -t SRV _kerberos._udp.ipa.example > on the client returns both IPA servers (in ANSWER section). > > -- > Petr^2 Spacek > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 12 18:41:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Feb 2014 13:41:53 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <52FBC071.3050602@redhat.com> Shree wrote: > OK I thought CA is a part of IPA ? Below is from my master IPA server > > [root at ldap ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [root at ldap ~]# > > I can certainly send you a log if needed. It is part of IPA but the IPA server talks to it, not the clients directly. I can only speculate what the client is doing without seeing the log files, but I suspect both masters are in DNS and IPA is trying to enroll to the initial master which isn't available. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden > wrote: > Shree wrote: > > Peter > > Actually I mentioned earlier that my clients are in a separate VLAN and > > cannot access the master. We have made provisions for the master and the > > replica to sync by opening the needed ports in the firewall. We have > > also opened up ports between the clients and the replica. I have tested > > the connectivity for these ports. > > Perhaps you can tell me if what I am trying to achieve is even possible? > > i.e > > I seem to get stuck with making the replica with the "--setup-ca" > > option. Wthout that option I am able to create a replica and have it in > > sync with the master. However my ipa-client-install fails from clients > > as they try looking for the master for CA part of the install. > > Clients don't talk to the CA, they talk to an IPA server which talks to > the CA. > > I think we need to see /var/log/ipaclient-install.log to see what is > going on. > > rob > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek > > > wrote: > > On 11.2.2014 23:53, Shree wrote: > > > > > Following ports are opened between the > > > 1) Between the master and the replica (bi directional) > > > 2) client machine and the ipa replica (unidirectional). > > > When the replica was up it worked fine as far as syncing was > concerned. > > > > > > 80 tcp > > > 443 tcp > > > 389 tcp > > > 636 tcp > > > 88 tcp > > > 464 tcp > > > 88 udp > > > 464 udp > > > 123 udp > > > > > > Shreeraj > > > > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > > > > > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > > >> wrote: > > > > > > On 02/11/2014 05:05 PM, Shree wrote: > > > Dimitri > > >> Sorry some the mail landed in my SPAM folder. Let answer your > > questions (thanks for your help man) > > > Please republish it on the list. > > > Do not reply to me directly. > > > > > > Did you set your first server with the CA? Does all ports that need > > > to be open in the firewall between primary or server are actually > > > open? > > > > > > > > > > > >> > > >> What I have done so far is uninstalled the replica and tried to > > install it again using the "--setup-ca" option. Previously I had > > failures and when I removed the "--setup-ca" option the installation > > succeeded (in a way). I understand now that I really need to fix the CA > > installation errors first. > > >> > > >> > > >> 1)The workaround helped me go forward a bit but I got stuck at this > > point see below > > >> =========== > > >> [1/3]: creating directory server user > > >> [2/3]: creating directory server instance > > >> [3/3]: restarting directory server > > >> Done configuring directory server for the CA (pkids). > > >> ipa : ERROR certmonger failed starting to track > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit > > status 1 > > >> Configuring certificate server (pki-cad): Estimated time 3 minutes > > 30 seconds > > >> [1/17]: creating certificate server user > > >> [2/17]: creating pki-ca instance > > >> [3/17]: configuring certificate server instance > > >> ipa : CRITICAL failed to configure ca instance Command > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - > > >> =========== > > >> 2) No we do not use IPA for a DNS server. > > >> > > >> > > >> 3)The reason for this could be that I had installed the replica > > without the "--setup-ca". > > >> > > >> Shreeraj > > >> > > > ---------------------------------------------------------------------------------------- > > >> > > >> > > >> > > >> Change is the only Constant ! > > >> > > >> > > >> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > > > >> wrote: > > >> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: > > >>> Shree wrote: > > >>>> Lukas > > >>>> Perhaps I should explain the design a bit and > > > see if FreeIPA even > > >>>> supports this.Our replica is in a separate > > > network and all the > > >>>> appropriate ports are opened between the master > > > and the replica. The > > >>>> "replica" got created successfully and is in > > > sync with the master > > >>>> (except the CA services which I mentioned > > > earlier) > > >>>> Now,when I try to run ipa-client-install on > > > hosts in the new network > > >>>> using the replica, it complains that about > > > "Cannot contact any KDC for > > >>>> realm". > > >>>> I am wondering it my hosts in the new network > > > are trying to access the > > >>>> "master" for certificates since the replica > > > does not have any CA > > >>>> services running? I couldn't find any obvious > > > proof of this even running > > >>>> the install in a debug mode. Do I need to open > > > ports between the new > > >>>> hosts and the master for CA services? > > >>>> At this point I cannot disable or move the > > > master, it needs to function > > >>>> in its location but I need > > >>> > > >>> No, the clients don't directly talk to the CA. > > >>> > > >>> You'd need to look in > > > /var/log/ipaclient-install.log to see what KDC > > >>> was found and we were trying to use. If you have > > > SRV records for both > > >>> but we try to contact the hidden master this will > > > happen. You can try > > >>> specifying the server on the command-line with > > > --server but this will > > >>> be hardcoding things and make it less flexible > > > later. > > >>> > > >>> rob > > >>> > > >>>> Shreeraj > > >>>> > > > > > > ---------------------------------------------------------------------------------------- > > >>>> > > >>>> > > >>>> > > >>>> Change is the only Constant ! > > >>>> > > >>>> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas > > > Slebodnik > > >>>> > >> wrote: > > >>>> On (06/02/14 18:33), Shree wrote: > > >>>> > > >>>>> First of all, the ipa-replica-install did > > > not allow me to use > > >>>> the --setup-ca > > >>>>> option complaining that a cert already > > > exists, replicate creation was > > >>>>> successful after I skipped the option. > > >>>>> Seems like the replica is one except > > >>>>> 1) There is no CA Service running on the > > > replica (which I guess is > > >>>> expected) > > >>>>> and > > >>>>> 2) I am unable to run ipa-client-install > > > successfully on any clients > > >>>> using > > >>>>> the replica. (I don't have the option of > > > using the primary master as > > >>>> it is > > >>>>> configured in a segregated environment. > > > Only the master and replica > > >>>> are > > >>>>> allowed to sync. > > >>>>> Debug shows it fails at > > >>>>> > > >>>>> ipa : DEBUG stderr=kinit: Cannot > > > contact any KDC for realm > > >>>> 'mydomainname.com' while getting initial > > > credentials > > >>>> > > >>>>> > > >>>>> > > >>>> > > >>>> I was not able to install replica witch CA on > > > fedora 20, > > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 > > >>>> > > >>>> Guys from dogtag found a workaround > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 > > >>>> > > >>>> Does it work for you? > > >>>> > > >>>> LS > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Freeipa-users mailing list > > >>>> Freeipa-users at redhat.com > > > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Freeipa-users mailing list > > >>> Freeipa-users at redhat.com > > > > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > >> > > >> What server provides DNS capabilities to the clients? > > >> Do you use IPA DNS or some other DNS? > > >> Clients seem to not be able to see replica KDC and try > > > to access hidden > > >> master but they can know about this master only via DNS. > > > > > > Shree, make sure that command > > $ dig -t SRV _kerberos._udp.ipa.example > > on the client returns both IPA servers (in ANSWER section). > > > > -- > > Petr^2 Spacek > > > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > From shreerajkarulkar at yahoo.com Wed Feb 12 19:09:54 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 11:09:54 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBC071.3050602@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> Message-ID: <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> Rob I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. [1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck ?This ended with a? Done configuring NTP daemon (ntpd). A CA is already configured on this system. [2] So did a pkiremove with the following command # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force [3] Re ran the ipa-replica-install command in step 1 The install went a little further but ended below. Configuring directory server for the CA (pkids): Estimated time 30 seconds ? [1/3]: creating directory server user ? [2/3]: creating directory server instance ? [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds ? [1/17]: creating certificate server user ? [2/17]: creating pki-ca instance ? [3/17]: configuring certificate server instance ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. ........................... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. Shreeraj ---------------------------------------------------------------------------------------- On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: Shree wrote: > OK I thought CA is a part of IPA ? Below is from my master IPA server > > [root at ldap ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [root at ldap ~]# > > I can certainly send you a log if needed. It is part of IPA but the IPA server talks to it, not the clients directly. I can only speculate what the client is doing without seeing the log files, but I suspect both masters are in DNS and IPA is trying to enroll to the initial master which isn't available. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden > wrote: > Shree wrote: >? > Peter >? > Actually I mentioned earlier that my clients are in a separate VLAN and >? > cannot access the master. We have made provisions for the master and the >? > replica to sync by opening the needed ports in the firewall. We have >? > also opened up ports between the clients and the replica. I have tested >? > the connectivity for these ports. >? > Perhaps you can tell me if what I am trying to achieve is even possible? >? > i.e >? > I seem to get stuck with making the replica with the "--setup-ca" >? > option. Wthout that option I am able to create a replica and have it in >? > sync with the master. However my ipa-client-install fails from clients >? > as they try looking for the master for CA part of the install. > > Clients don't talk to the CA, they talk to an IPA server which talks to > the CA. > > I think we need to see /var/log/ipaclient-install.log to see what is > going on. > > rob > >? > Shreeraj >? > > ---------------------------------------------------------------------------------------- >? > >? > >? > Change is the only Constant ! >? > >? > >? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >? > > wrote: >? > On 11.2.2014 23:53, Shree wrote: >? > >? >? > Following ports are opened between the >? >? > 1) Between the master and the replica (bi directional) >? >? > 2) client machine and the ipa replica (unidirectional). >? >? > When the replica was up it worked fine as far as syncing was > concerned. >? >? > >? >? >? 80 tcp >? >? >? 443 tcp >? >? >? 389 tcp >? >? >? 636 tcp >? >? >? 88 tcp >? >? >? 464 tcp >? >? >? 88 udp >? >? >? 464 udp >? >? >? 123 udp >? >? > >? >? > Shreeraj >? >? > >? > > ---------------------------------------------------------------------------------------- >? >? > >? >? > Change is the only Constant ! >? >? > >? >? > >? >? > >? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >? > >> wrote: >? >? > >? >? > On 02/11/2014 05:05 PM, Shree wrote: >? >? > Dimitri >? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >? > questions (thanks for your help man) >? >? > Please republish it on the list. >? >? > Do not reply to me directly. >? >? > >? >? > Did you set your first server with the CA? Does all ports that need >? >? >? ? ? to be open in the firewall between primary or server are actually >? >? >? ? ? open? >? >? > >? >? > >? >? > >? >? >> >? >? >> What I have done so far is uninstalled the replica and tried to >? > install it again using the "--setup-ca" option. Previously I had >? > failures and when I removed the "--setup-ca" option the installation >? > succeeded (in a way). I understand now that I really need to fix the CA >? > installation errors first. >? >? >> >? >? >> >? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >? > point see below >? >? >> =========== >? >? >>? ? [1/3]: creating directory server user >? >? >>? ? [2/3]: creating directory server instance >? >? >>? ? [3/3]: restarting directory server >? >? >> Done configuring directory server for the CA (pkids). >? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >? > status 1 >? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >? > 30 seconds >? >? >>? ? [1/17]: creating certificate server user >? >? >>? ? [2/17]: creating pki-ca instance >? >? >>? ? [3/17]: configuring certificate server instance >? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >? >? >> =========== >? >? >> 2) No we do not use IPA for a DNS server. >? >? >> >? >? >> >? >? >> 3)The reason for this could be that I had installed the replica >? > without the "--setup-ca". >? >? >> >? >? >> Shreeraj >? >? >> >? > > ---------------------------------------------------------------------------------------- >? >? >> >? >? >> >? > >> >? >? >> Change is the only Constant ! >? >? >> >? >? >> >? >? >> >? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > >? > >> wrote: >? >? >> >? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >? >? >>> Shree wrote: >? >? >>>> Lukas >? >? >>>> Perhaps I should explain the design a bit and >? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >? >? >>>> supports this.Our replica is in a separate >? >? >? ? ? ? ? ? ? ? ? network and all the >? >? >>>> appropriate ports are opened between the master >? >? >? ? ? ? ? ? ? ? ? and the replica. The >? >? >>>> "replica" got created successfully and is in >? >? >? ? ? ? ? ? ? ? ? sync with the master >? >? >>>> (except the CA services which I mentioned >? >? >? ? ? ? ? ? ? ? ? earlier) >? >? >>>> Now,when I try to run ipa-client-install on >? >? >? ? hosts in the new network >? >? >>>> using the replica, it complains that about >? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >? >? >>>> realm". >? >? >>>> I am wondering it my hosts in the new network >? >? >? ? ? ? ? ? ? ? ? are trying to access the >? >? >>>> "master" for certificates since the replica >? >? >? ? ? ? ? ? ? ? ? does not have any CA >? >? >>>> services running? I couldn't find any obvious >? >? >? ? ? ? ? ? ? ? ? proof of this even running >? >? >>>> the install in a debug mode. Do I need to open >? >? >? ? ? ? ? ? ? ? ? ports between the new >? >? >>>> hosts and the master for CA services? >? >? >>>> At this point I cannot disable or? move the >? >? >? ? ? ? ? ? ? ? ? master, it needs to function >? >? >>>> in its location but I need >? >? >>> >? >? >>> No, the clients don't directly talk to the CA. >? >? >>> >? >? >>> You'd need to look in >? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >? >? >>> was found and we were trying to use. If you have >? >? >? ? ? ? ? ? ? ? ? SRV records for both >? >? >>> but we try to contact the hidden master this will >? >? >? ? ? ? ? ? ? ? ? happen. You can try >? >? >>> specifying the server on the command-line with >? >? >? ? ? ? ? ? ? ? ? --server but this will >? >? >>> be hardcoding things and make it less flexible >? >? >? ? ? ? ? ? ? ? ? later. >? >? >>> >? >? >>> rob >? >? >>> >? >? >>>> Shreeraj >? >? >>>> >? >? > >? > > ---------------------------------------------------------------------------------------- >? >? >>>> >? >? >>>> >? >? >>>> >? >? >>>> Change is the only Constant ! >? >? >>>> >? >? >>>> >? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >? >? >? ? ? ? ? ? ? ? ? Slebodnik >? >? >>>> > >> wrote: >? >? >>>> On (06/02/14 18:33), Shree wrote: >? >? >>>> >? >? >>>>> First of all, the ipa-replica-install did >? >? >? ? ? ? ? ? ? ? ? not allow me to use >? >? >>>> the --setup-ca >? >? >>>>> option complaining that a cert already >? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >? >? >>>>> successful after I skipped the option. >? >? >>>>> Seems like the replica is one except >? >? >>>>> 1) There is no CA Service running on the >? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >? > >>>> expected) >? >? >>>>> and >? >? >>>>> 2) I am unable to run ipa-client-install >? >? >? ? ? ? ? ? ? ? ? successfully on any clients >? >? >>>> using >? >? >>>>> the replica. (I don't have the option of >? >? >? ? ? ? ? ? ? ? ? using the primary master as >? >? >>>> it is >? >? >>>>> configured in a segregated environment. >? >? >? ? ? ? ? ? ? ? ? Only the master and replica >? >? >>>> are >? >? >>>>> allowed to sync. >? > >>>>> Debug shows it fails at >? >? >>>>> >? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >? >? >>>> 'mydomainname.com' while getting initial >? >? >? ? ? ? ? ? ? ? ? credentials >? >? >>>> >? >? >>>>> >? >? >>>>> >? >? >>>> >? >? >>>> I was not able to install replica witch CA on >? >? >? ? ? ? ? ? ? ? ? fedora 20, >? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >? >? >>>> >? >? >>>> Guys from dogtag found a workaround >? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >? >? >>>> >? >? >>>> Does it work for you? >? >? >>>> >? >? >>>> LS >? >? >>>> >? >? >>>> >? >? >>>> >? >? >>>> >? >? >>>> >? >? >>>> _______________________________________________ >? >? >>>> Freeipa-users mailing list >? >? >>>> Freeipa-users at redhat.com > > >? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >? >>>> >? >? >>> >? >? >>> _______________________________________________ >? >? >>> Freeipa-users mailing list >? >? >>> Freeipa-users at redhat.com > > > >? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >? >> >? >? >> What server provides DNS capabilities to the clients? >? >? >> Do you use IPA DNS or some other DNS? >? >? >> Clients seem to not be able to see replica KDC and try >? >? >? ? ? ? ? ? ? ? ? to access hidden >? >? >> master but they can know about this master only via DNS. >? > >? > >? > Shree, make sure that command >? > $ dig -t SRV _kerberos._udp.ipa.example >? > on the client returns both IPA servers (in ANSWER section). >? > >? > -- >? > Petr^2 Spacek >? > >? > >? > >? > >? > >? > _______________________________________________ >? > Freeipa-users mailing list >? > Freeipa-users at redhat.com >? > https://www.redhat.com/mailman/listinfo/freeipa-users >? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 12 19:37:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 14:37:50 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <52FBCD8E.8060705@redhat.com> On 02/12/2014 02:09 PM, Shree wrote: > Rob > I really appreciate your help, please bear with me. At this point I > need to take you back to my ipa-replica-install and what happened there. > > [1] My command: ipa-replica-install --setup-ca > /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck > This ended with a > Done configuring NTP daemon (ntpd). > A CA is already configured on this system. > > [2] So did a pkiremove with the following command > # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > [3] Re ran the ipa-replica-install command in step 1 > The install went a little further but ended below. > > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > Done configuring directory server for the CA (pkids). > ipa : ERROR certmonger failed starting to track > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero > exit status 1 > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ................. > ........................... > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > If I skip the "--setup-ca" option then the replica gets created > without any CA services. The "master" and "replica" are in sync but I > am unable to run a ipa-client-install using the replica. Now I need > to fix this to get a replica in place correctly. > > > Shreeraj > ---------------------------------------------------------------------------------------- > > > > On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden > wrote: > Shree wrote: > > OK I thought CA is a part of IPA ? Below is from my master IPA server > > > > [root at ldap ~]# ipactl status > > Directory Service: RUNNING > > KDC Service: RUNNING > > KPASSWD Service: RUNNING > > MEMCACHE Service: RUNNING > > HTTP Service: RUNNING > > CA Service: RUNNING > > [root at ldap ~]# > > > > I can certainly send you a log if needed. > > It is part of IPA but the IPA server talks to it, not the clients > directly. > > I can only speculate what the client is doing without seeing the log > files, but I suspect both masters are in DNS and IPA is trying to enroll > to the initial master which isn't available. > > rob > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden > > > wrote: > > Shree wrote: > > > Peter > > > Actually I mentioned earlier that my clients are in a separate > VLAN and > > > cannot access the master. We have made provisions for the master > and the > > > replica to sync by opening the needed ports in the firewall. We have > > > also opened up ports between the clients and the replica. I have > tested > > > the connectivity for these ports. > > > Perhaps you can tell me if what I am trying to achieve is even > possible? > > > i.e > > > I seem to get stuck with making the replica with the "--setup-ca" > > > option. Wthout that option I am able to create a replica and have > it in > > > sync with the master. However my ipa-client-install fails from clients > > > as they try looking for the master for CA part of the install. > > > > Clients don't talk to the CA, they talk to an IPA server which talks to > > the CA. > > > > I think we need to see /var/log/ipaclient-install.log to see what is > > going on. > > > > rob > > > > > Shreeraj > > > > > > ---------------------------------------------------------------------------------------- > > > > > > > > > Change is the only Constant ! > > > > > > > > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek > > > > >> wrote: > > > On 11.2.2014 23:53, Shree wrote: > > > > > > > Following ports are opened between the > > > > 1) Between the master and the replica (bi directional) > > > > 2) client machine and the ipa replica (unidirectional). > > > > When the replica was up it worked fine as far as syncing was > > concerned. > > > > > > > > 80 tcp > > > > 443 tcp > > > > 389 tcp > > > > 636 tcp > > > > 88 tcp > > > > 464 tcp > > > > 88 udp > > > > 464 udp > > > > 123 udp > > > > > > > > Shreeraj > > > > > > > > > > ---------------------------------------------------------------------------------------- > > > > > > > > Change is the only Constant ! > > > > > > > > > > > > > > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > > > > > > > > >>> wrote: > > > > > > > > On 02/11/2014 05:05 PM, Shree wrote: > > > > Dimitri > > > >> Sorry some the mail landed in my SPAM folder. Let answer your > > > questions (thanks for your help man) > > > > Please republish it on the list. > > > > Do not reply to me directly. > > > > > > > > Did you set your first server with the CA? Does all ports that need > > > > to be open in the firewall between primary or server are > actually > > > > open? > > > > > > > > > > > > > > > >> > > > >> What I have done so far is uninstalled the replica and tried to > > > install it again using the "--setup-ca" option. Previously I had > > > failures and when I removed the "--setup-ca" option the installation > > > succeeded (in a way). I understand now that I really need to fix > the CA > > > installation errors first. > > > >> > > > >> > > > >> 1)The workaround helped me go forward a bit but I got stuck at this > > > point see below > > > >> =========== > > > >> [1/3]: creating directory server user > > > >> [2/3]: creating directory server instance > > > >> [3/3]: restarting directory server > > > >> Done configuring directory server for the CA (pkids). > > > >> ipa : ERROR certmonger failed starting to track > > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned > non-zero exit > > > status 1 > > > >> Configuring certificate server (pki-cad): Estimated time 3 minutes > > > 30 seconds > > > >> [1/17]: creating certificate server user > > > >> [2/17]: creating pki-ca instance > > > >> [3/17]: configuring certificate server instance > > > >> ipa : CRITICAL failed to configure ca instance Command > > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT > > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - > > > >> =========== > > > >> 2) No we do not use IPA for a DNS server. > > > >> > > > >> > > > >> 3)The reason for this could be that I had installed the replica > > > without the "--setup-ca". > > > >> > > > >> Shreeraj > > > >> > > > > > > ---------------------------------------------------------------------------------------- > > > >> > > > >> > > > >> > > > >> Change is the only Constant ! > > > >> > > > >> > > > >> > > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > > > > > > > >>> wrote: > > > >> > > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: > > > >>> Shree wrote: > > > >>>> Lukas > > > >>>> Perhaps I should explain the design a bit and > > > > see if FreeIPA even > > > >>>> supports this.Our replica is in a separate > > > > network and all the > > > >>>> appropriate ports are opened between the master > > > > and the replica. The > > > >>>> "replica" got created successfully and is in > > > > sync with the master > > > >>>> (except the CA services which I mentioned > > > > earlier) > > > >>>> Now,when I try to run ipa-client-install on > > > > hosts in the new network > > > >>>> using the replica, it complains that about > > > > "Cannot contact any KDC for > > > >>>> realm". > > > >>>> I am wondering it my hosts in the new network > > > > are trying to access the > > > >>>> "master" for certificates since the replica > > > > does not have any CA > > > >>>> services running? I couldn't find any obvious > > > > proof of this even running > > > >>>> the install in a debug mode. Do I need to open > > > > ports between the new > > > >>>> hosts and the master for CA services? > > > >>>> At this point I cannot disable or move the > > > > master, it needs to function > > > >>>> in its location but I need > > > >>> > > > >>> No, the clients don't directly talk to the CA. > > > >>> > > > >>> You'd need to look in > > > > /var/log/ipaclient-install.log to see what KDC > > > >>> was found and we were trying to use. If you have > > > > SRV records for both > > > >>> but we try to contact the hidden master this will > > > > happen. You can try > > > >>> specifying the server on the command-line with > > > > --server but this will > > > >>> be hardcoding things and make it less flexible > > > > later. > > > >>> > > > >>> rob > > > >>> > > > >>>> Shreeraj > > > >>>> > > > > > > > > > > ---------------------------------------------------------------------------------------- > > > >>>> > > > >>>> > > > >>>> > > > >>>> Change is the only Constant ! > > > >>>> > > > >>>> > > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas > > > > Slebodnik > > > >>>> > > > > > >>> wrote: > > > >>>> On (06/02/14 18:33), Shree wrote: > > > >>>> > > > >>>>> First of all, the ipa-replica-install did > > > > not allow me to use > > > >>>> the --setup-ca > > > >>>>> option complaining that a cert already > > > > exists, replicate creation was > > > >>>>> successful after I skipped the option. > > > >>>>> Seems like the replica is one except > > > >>>>> 1) There is no CA Service running on the > > > > replica (which I guess is > > > >>>> expected) > > > >>>>> and > > > >>>>> 2) I am unable to run ipa-client-install > > > > successfully on any clients > > > >>>> using > > > >>>>> the replica. (I don't have the option of > > > > using the primary master as > > > >>>> it is > > > >>>>> configured in a segregated environment. > > > > Only the master and replica > > > >>>> are > > > >>>>> allowed to sync. > > > >>>>> Debug shows it fails at > > > >>>>> > > > >>>>> ipa : DEBUG stderr=kinit: Cannot > > > > contact any KDC for realm > > > >>>> 'mydomainname.com' while getting initial > > > > credentials > > > >>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> I was not able to install replica witch CA on > > > > fedora 20, > > > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 > > > >>>> > > > >>>> Guys from dogtag found a workaround > > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 > > > >>>> > > > >>>> Does it work for you? > > > >>>> > > > >>>> LS > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Freeipa-users mailing list > > > >>>> Freeipa-users at redhat.com > > > > > >> > > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> Freeipa-users mailing list > > > >>> Freeipa-users at redhat.com > > > > > >> > > > > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > >> > > > >> What server provides DNS capabilities to the clients? > > > >> Do you use IPA DNS or some other DNS? > > > >> Clients seem to not be able to see replica KDC and try > > > > to access hidden > > > >> master but they can know about this master only via DNS. > > > > > > > > > Shree, make sure that command > > > $ dig -t SRV _kerberos._udp.ipa.example > > > on the client returns both IPA servers (in ANSWER section). > > > > > > -- > > > Petr^2 Spacek > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. I suspect that CA related communication between replica and master is not going through for some reasons. The install log would be really helpful. Please see http://www.freeipa.org/page/Troubleshooting to collect the right logs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jokajak at gmail.com Wed Feb 12 20:15:31 2014 From: jokajak at gmail.com (Josh) Date: Wed, 12 Feb 2014 15:15:31 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <52FA7F83.1070709@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> Message-ID: <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> On Feb 11, 2014, at 2:52 PM, Rob Crittenden wrote: > Josh wrote: >> >> On Feb 11, 2014, at 2:44 PM, Rob Crittenden > > wrote: >> >>> Josh wrote: >>>> I have a situation where I need to support more than 1024 categories >>>> on a system. I modified the selinuxusermap.py file to check for the >>>> number of categories I need but ipa still responds with the original >>>> error message. Do I need to restart any of the services? >>>> >>>> Here is the command that was run and the output after applying the >>>> patch below: >>>> >>>> ipa config-mod >>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>> >>> Have you updated your SELinux policy to support a larger MCS range? If >>> not then this will get you past the IPA validator but it won't work >>> with SELinux. See semanage(8). >>> >>> rob >> >> Yes. I?m trying to set the SELinux categories in freeipa because when >> you have lots of categories all semanage commands slow down (way down). >> For other people?s knowledge, this requires recompilation of the >> SELinux policy. > > Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. As it is for a very unique situation which most people won?t encounter I don?t think it?s worth making configurable. > > Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. I?m ok with that because the values only need to be set during initial setup. Any idea why the validator isn?t being modified? > > I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. > > regards > > rob > Thanks for the help. -josh >> >> -josh >> >>> >>>> >>>> Thanks, >>>> -josh >>>> >>>> PS: This is the patch that was applied >>>> >>>> --- >>>> /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py.cats 2014-02-11 >>>> 13:18:19.868574971 -0500 >>>> +++ /usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py >>>> 2014-02-11 13:20:03.563127380 -0500 >>>> @@ -99,9 +99,9 @@ def validate_selinuxuser(ugettext, user) >>>> if not mls or not regex_mls.match(mls): >>>> return _('Invalid MLS value, must match s[0-15](-s[0-15])') >>>> m = regex_mcs.match(mcs) >>>> - if mcs and (not m or (m.group(3) and (int(m.group(3)) > 1023))): >>>> - return _('Invalid MCS value, must match c[0-1023].c[0-1023] ' >>>> - 'and/or c[0-1023]-c[0-c0123]') >>>> + if mcs and (not m or (m.group(3) and (int(m.group(3)) > 16384))): >>>> + return _('Invalid MCS value, must match c[0-16384].c[0-16384] ' >>>> + 'and/or c[0-16384]-c[0-16384]') >>>> return None >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From rcritten at redhat.com Wed Feb 12 20:20:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Feb 2014 15:20:18 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> Message-ID: <52FBD782.6080903@redhat.com> Josh wrote: > > On Feb 11, 2014, at 2:52 PM, Rob Crittenden wrote: > >> Josh wrote: >>> >>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >> > wrote: >>> >>>> Josh wrote: >>>>> I have a situation where I need to support more than 1024 categories >>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>> number of categories I need but ipa still responds with the original >>>>> error message. Do I need to restart any of the services? >>>>> >>>>> Here is the command that was run and the output after applying the >>>>> patch below: >>>>> >>>>> ipa config-mod >>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>> >>>> Have you updated your SELinux policy to support a larger MCS range? If >>>> not then this will get you past the IPA validator but it won't work >>>> with SELinux. See semanage(8). >>>> >>>> rob >>> >>> Yes. I?m trying to set the SELinux categories in freeipa because when >>> you have lots of categories all semanage commands slow down (way down). >>> For other people?s knowledge, this requires recompilation of the >>> SELinux policy. >> >> Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. > > As it is for a very unique situation which most people won?t encounter I don?t think it?s worth making configurable. >> >> Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. > > I?m ok with that because the values only need to be set during initial setup. Any idea why the validator isn?t being modified? >> >> I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. >> >> regards >> >> rob >> > > Thanks for the help. Sure. I'm glad we made at least obvious enough for you to be able to work around. So I'm just curious about the need for this. You mentioned that semanage slows way down. Have you talked to the SELinux team about this? They've been quite responsive to our needs in the past, they may be able to fix something for you as well. On a more general note, we haven't had a lot of user feedback on the SELinux user map feature. Do you have any other suggestions on things we might do to improve it? thanks rob From jokajak at gmail.com Wed Feb 12 20:33:04 2014 From: jokajak at gmail.com (Josh) Date: Wed, 12 Feb 2014 15:33:04 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <52FBD782.6080903@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> <52FBD782.6080903@redhat.com> Message-ID: On Feb 12, 2014, at 3:20 PM, Rob Crittenden wrote: > Josh wrote: >> >> On Feb 11, 2014, at 2:52 PM, Rob Crittenden wrote: >> >>> Josh wrote: >>>> >>>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >>> > wrote: >>>> >>>>> Josh wrote: >>>>>> I have a situation where I need to support more than 1024 categories >>>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>>> number of categories I need but ipa still responds with the original >>>>>> error message. Do I need to restart any of the services? >>>>>> >>>>>> Here is the command that was run and the output after applying the >>>>>> patch below: >>>>>> >>>>>> ipa config-mod >>>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>>> >>>>> Have you updated your SELinux policy to support a larger MCS range? If >>>>> not then this will get you past the IPA validator but it won't work >>>>> with SELinux. See semanage(8). >>>>> >>>>> rob >>>> >>>> Yes. I?m trying to set the SELinux categories in freeipa because when >>>> you have lots of categories all semanage commands slow down (way down). >>>> For other people?s knowledge, this requires recompilation of the >>>> SELinux policy. >>> >>> Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. >> >> As it is for a very unique situation which most people won?t encounter I don?t think it?s worth making configurable. >>> >>> Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. >> >> I?m ok with that because the values only need to be set during initial setup. Any idea why the validator isn?t being modified? >>> >>> I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. >>> >>> regards >>> >>> rob >>> >> >> Thanks for the help. > > Sure. I'm glad we made at least obvious enough for you to be able to work around. > > So I'm just curious about the need for this. You mentioned that semanage slows way down. Have you talked to the SELinux team about this? They've been quite responsive to our needs in the past, they may be able to fix something for you as well. I?m not sure if my coworker has talked to them about it directly, no. I?ll ping him to see if it?s something we want to get worked on moving forward. > > On a more general note, we haven't had a lot of user feedback on the SELinux user map feature. Do you have any other suggestions on things we might do to improve it? Nothing directly but I can describe how we?re using it and where some of the perceived pain points are. Their impact is negligible though so we haven?t felt the need to investigate better ways to work around them. We?ve got a network of systems running both targeted and MLS SELinux policy. What this means is that we must define both valid selinux context is the user map. I.e. we define both staff_u:s0-s0:c0.c1023 and staff_u:s0-s15:c0.c1023 in the user map. We then use host groups and multiple user maps to map appropriately. Our commands might be easier to understand: ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$staff_u:s0-s15:c0.c1023? ipa hostgroup-add mls --desc="MLS SELinux Group? ipa hostgroup-add-member mls --hosts=mlshost1,mlshost2 ipa hostgroup-add targeted --desc="Targeted SELinux Group? ipa hostgroup-add-member targeted --hosts=appsrv1,appsrv2 ipa selinuxusermap-add staff_u --selinuxuser=staff_u:s0-s0:c0.c1023 ipa selinuxusermap-add staff_u_MLS --selinuxuser=staff_u:s0-s15:c0.c1023 ipa selinuxusermap-add-host staff_u --hostgroups=targeted ipa selinuxusermap-add-host staff_u_MLS --hostgroups=mls ipa selinuxusermap-add-user staff_u --groups=wheel ipa selinuxusermap-add-user staff_u_MLS --groups=wheel It might be more straightforward if we didn?t have to split the configuration like this but thanks to the flexibility of FreeIPA it?s very easy to do. Thanks, -josh > > thanks > > rob From shreerajkarulkar at yahoo.com Wed Feb 12 20:41:34 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 12:41:34 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBCD8E.8060705@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> Message-ID: <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> So I uninstalled the ipa server and installed the client (ipa-client-install) on the same VM pointing at the master and everything seems to work OK. All the sudo rules etc. Are there any tests I can do check connectivity that could be helpful before I configure this as a "replica" again. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal wrote: On 02/12/2014 02:09 PM, Shree wrote: Rob >I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. > > >[1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >?This ended with a? >Done configuring NTP daemon (ntpd). >A CA is already configured on this system. > > >[2] So did a pkiremove with the following command ># pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > > >[3] Re ran the ipa-replica-install command in step 1 >The install went a little further but ended below. > > >Configuring directory server for the CA (pkids): Estimated time 30 seconds >? [1/3]: creating directory server user >? [2/3]: creating directory server instance >? [3/3]: restarting directory server >Done configuring directory server for the CA (pkids). >ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >? [1/17]: creating certificate server user >? [2/17]: creating pki-ca instance >? [3/17]: configuring certificate server instance >ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. >........................... >Your system may be partly configured. >Run /usr/sbin/ipa-server-install --uninstall to clean up. > > >Configuration of CA failed > > >If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. > > > > >Shreeraj >---------------------------------------------------------------------------------------- > > > > >On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: > >Shree wrote: >> OK I thought CA is a part of IPA ? Below is from my master IPA server >> >> [root at ldap ~]# ipactl status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> CA Service: RUNNING >> [root at ldap ~]# >> >> I can certainly send you a log if needed. > >It is part of IPA but the IPA server talks to it, not the clients directly. > >I can only speculate what the client is doing without seeing the log >files, but I suspect both masters are in DNS and IPA is trying to enroll >to the initial master which isn't available. > >rob > >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >> wrote: >> Shree wrote: >>? > Peter >>? > Actually I mentioned earlier that my clients are in a separate VLAN and >>? > cannot access the master. We have made provisions for the master and the >>? > replica to sync by opening the needed ports in the firewall. We have >>? > also opened up ports between the clients and the replica. I have tested >>? > the connectivity for these ports. >>? > Perhaps you can tell me if what I am trying to achieve is even possible? >>? > i.e >>? > I seem to get stuck with making the replica with the "--setup-ca" >>? > option. Wthout that option I am able to create a replica and have it in >>? > sync with the master. However my ipa-client-install fails from clients >>? > as they try looking for the master for CA part of the install. >> >> Clients don't talk to the CA, they talk to an IPA server which talks to >> the CA. >> >> I think we need to see /var/log/ipaclient-install.log to see what is >> going on. >> >> rob >> >>? > Shreeraj >>? > >> ---------------------------------------------------------------------------------------- >>? > >>? > >>? > Change is the only Constant ! >>? > >>? > >>? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>? > > wrote: >>? > On 11.2.2014 23:53, Shree wrote: >>? > >>? >? > Following ports are opened between the >>? >? > 1) Between the master and the replica (bi directional) >>? >? > 2) client machine and the ipa replica (unidirectional). >>? >? > When the replica was up it worked fine as far as syncing was >> concerned. >>? >? > >>? >? >? 80 tcp >>? >? >? 443 tcp >>? >? >? 389 tcp >>? >? >? 636 tcp >>? >? >? 88 tcp >>? >? >? 464 tcp >>? >? >? 88 udp >>? >? >? 464 udp >>? >? >? 123 udp >>? >? > >>? >? > Shreeraj >>? >? > >>? > >> ---------------------------------------------------------------------------------------- >>? >? > >>? >? > Change is the only Constant ! >>? >? > >>? >? > >>? >? > >>? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > >>? > >> wrote: >>? >? > >>? >? > On 02/11/2014 05:05 PM, Shree wrote: >>? >? > Dimitri >>? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >>? > questions (thanks for your help man) >>? >? > Please republish it on the list. >>? >? > Do not reply to me directly. >>? >? > >>? >? > Did you set your first server with the CA? Does all ports that need >>? >? >? ? ? to be open in the firewall between primary or server are actually >>? >? >? ? ? open? >>? >? > >>? >? > >>? >? > >>? >? >> >>? >? >> What I have done so far is uninstalled the replica and tried to >>? > install it again using the "--setup-ca" option. Previously I had >>? > failures and when I removed the "--setup-ca" option the installation >>? > succeeded (in a way). I understand now that I really need to fix the CA >>? > installation errors first. >>? >? >> >>? >? >> >>? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >>? > point see below >>? >? >> =========== >>? >? >>? ? [1/3]: creating directory server user >>? >? >>? ? [2/3]: creating directory server instance >>? >? >>? ? [3/3]: restarting directory server >>? >? >> Done configuring directory server for the CA (pkids). >>? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >>? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >>? > status 1 >>? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >>? > 30 seconds >>? >? >>? ? [1/17]: creating certificate server user >>? >? >>? ? [2/17]: creating pki-ca instance >>? >? >>? ? [3/17]: configuring certificate server instance >>? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >>? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >>? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>? >? >> =========== >>? >? >> 2) No we do not use IPA for a DNS server. >>? >? >> >>? >? >> >>? >? >> 3)The reason for this could be that I had installed the replica >>? > without the "--setup-ca". >>? >? >> >>? >? >> Shreeraj >>? >? >> >>? > >> ---------------------------------------------------------------------------------------- >>? >? >> >>? >? >> >>? > >> >>? >? >> Change is the only Constant ! >>? >? >> >>? >? >> >>? >? >> >>? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >> >>? > >> wrote: >>? >? >> >>? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>? >? >>> Shree wrote: >>? >? >>>> Lukas >>? >? >>>> Perhaps I should explain the design a bit and >>? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >>? >? >>>> supports this.Our replica is in a separate >>? >? >? ? ? ? ? ? ? ? ? network and all the >>? >? >>>> appropriate ports are opened between the master >>? >? >? ? ? ? ? ? ? ? ? and the replica. The >>? >? >>>> "replica" got created successfully and is in >>? >? >? ? ? ? ? ? ? ? ? sync with the master >>? >? >>>> (except the CA services which I mentioned >>? >? >? ? ? ? ? ? ? ? ? earlier) >>? >? >>>> Now,when I try to run ipa-client-install on >>? >? >? ? hosts in the new network >>? >? >>>> using the replica, it complains that about >>? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>? >? >>>> realm". >>? >? >>>> I am wondering it my hosts in the new network >>? >? >? ? ? ? ? ? ? ? ? are trying to access the >>? >? >>>> "master" for certificates since the replica >>? >? >? ? ? ? ? ? ? ? ? does not have any CA >>? >? >>>> services running? I couldn't find any obvious >>? >? >? ? ? ? ? ? ? ? ? proof of this even running >>? >? >>>> the install in a debug mode. Do I need to open >>? >? >? ? ? ? ? ? ? ? ? ports between the new >>? >? >>>> hosts and the master for CA services? >>? >? >>>> At this point I cannot disable or? move the >>? >? >? ? ? ? ? ? ? ? ? master, it needs to function >>? >? >>>> in its location but I need >>? >? >>> >>? >? >>> No, the clients don't directly talk to the CA. >>? >? >>> >>? >? >>> You'd need to look in >>? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>? >? >>> was found and we were trying to use. If you have >>? >? >? ? ? ? ? ? ? ? ? SRV records for both >>? >? >>> but we try to contact the hidden master this will >>? >? >? ? ? ? ? ? ? ? ? happen. You can try >>? >? >>> specifying the server on the command-line with >>? >? >? ? ? ? ? ? ? ? ? --server but this will >>? >? >>> be hardcoding things and make it less flexible >>? >? >? ? ? ? ? ? ? ? ? later. >>? >? >>> >>? >? >>> rob >>? >? >>> >>? >? >>>> Shreeraj >>? >? >>>> >>? >? > >>? > >> ---------------------------------------------------------------------------------------- >>? >? >>>> >>? >? >>>> >>? >? >>>> >>? >? >>>> Change is the only Constant ! >>? >? >>>> >>? >? >>>> >>? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>? >? >? ? ? ? ? ? ? ? ? Slebodnik >>? >? >>>> >> >> wrote: >>? >? >>>> On (06/02/14 18:33), Shree wrote: >>? >? >>>> >>? >? >>>>> First of all, the ipa-replica-install did >>? >? >? ? ? ? ? ? ? ? ? not allow me to use >>? >? >>>> the --setup-ca >>? >? >>>>> option complaining that a cert already >>? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >>? >? >>>>> successful after I skipped the option. >>? >? >>>>> Seems like the replica is one except >>? >? >>>>> 1) There is no CA Service running on the >>? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >>? > >>>> expected) >>? >? >>>>> and >>? >? >>>>> 2) I am unable to run ipa-client-install >>? >? >? ? ? ? ? ? ? ? ? successfully on any clients >>? >? >>>> using >>? >? >>>>> the replica. (I don't have the option of >>? >? >? ? ? ? ? ? ? ? ? using the primary master as >>? >? >>>> it is >>? >? >>>>> configured in a segregated environment. >>? >? >? ? ? ? ? ? ? ? ? Only the master and replica >>? >? >>>> are >>? >? >>>>> allowed to sync. >>? > >>>>> Debug shows it fails at >>? >? >>>>> >>? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >>? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >>? >? >>>> 'mydomainname.com' while getting initial >>? >? >? ? ? ? ? ? ? ? ? credentials >>? >? >>>> >>? >? >>>>> >>? >? >>>>> >>? >? >>>> >>? >? >>>> I was not able to install replica witch CA on >>? >? >? ? ? ? ? ? ? ? ? fedora 20, >>? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>? >? >>>> >>? >? >>>> Guys from dogtag found a workaround >>? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>? >? >>>> >>? >? >>>> Does it work for you? >>? >? >>>> >>? >? >>>> LS >>? >? >>>> >>? >? >>>> >>? >? >>>> >>? >? >>>> >>? >? >>>> >>? >? >>>> _______________________________________________ >>? >? >>>> Freeipa-users mailing list >>? >? >>>> Freeipa-users at redhat.com >> > >>? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>? >? >>>> >>? >? >>> >>? >? >>> _______________________________________________ >>? >? >>> Freeipa-users mailing list >>? >? >>> Freeipa-users at redhat.com >> > >> >>? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>? >? >> >>? >? >> What server provides DNS capabilities to the clients? >>? >? >> Do you use IPA DNS or some other DNS? >>? >? >> Clients seem to not be able to see replica KDC and try >>? >? >? ? ? ? ? ? ? ? ? to access hidden >>? >? >> master but they can know about this master only via DNS. >>? > >>? > >>? > Shree, make sure that command >>? > $ dig -t SRV _kerberos._udp.ipa.example >>? > on the client returns both IPA servers (in ANSWER section). >>? > >>? > -- >>? > Petr^2 Spacek >>? > >>? > >>? > >>? > >>? > >>? > _______________________________________________ >>? > Freeipa-users mailing list >>? > Freeipa-users at redhat.com >>? > https://www.redhat.com/mailman/listinfo/freeipa-users >>? > >> >> >> > > > > > > >_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. I suspect that CA related communication between replica and master is not going through for some reasons. The install log would be really helpful. Please see http://www.freeipa.org/page/Troubleshooting to collect the right logs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 12 20:43:04 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 15:43:04 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <52FBDCD8.2080800@redhat.com> On 02/12/2014 03:41 PM, Shree wrote: > So I uninstalled the ipa server and installed the client > (ipa-client-install) on the same VM pointing at the master and > everything seems to work OK. All the sudo rules etc. Are there any > tests I can do check connectivity that could be helpful before I > configure this as a "replica" again. Ask certmonger to get a certificate > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal > wrote: > On 02/12/2014 02:09 PM, Shree wrote: >> Rob >> I really appreciate your help, please bear with me. At this point I >> need to take you back to my ipa-replica-install and what happened there. >> >> [1] My command: ipa-replica-install --setup-ca >> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >> This ended with a >> Done configuring NTP daemon (ntpd). >> A CA is already configured on this system. >> >> [2] So did a pkiremove with the following command >> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >> >> [3] Re ran the ipa-replica-install command in step 1 >> The install went a little further but ended below. >> >> Configuring directory server for the CA (pkids): Estimated time 30 >> seconds >> [1/3]: creating directory server user >> [2/3]: creating directory server instance >> [3/3]: restarting directory server >> Done configuring directory server for the CA (pkids). >> ipa : ERROR certmonger failed starting to track >> certificate: Command '/usr/bin/ipa-getcert start-tracking -d >> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero >> exit status 1 >> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 >> seconds >> [1/17]: creating certificate server user >> [2/17]: creating pki-ca instance >> [3/17]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >> ................. >> ........................... >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Configuration of CA failed >> >> If I skip the "--setup-ca" option then the replica gets created >> without any CA services. The "master" and "replica" are in sync but I >> am unable to run a ipa-client-install using the replica. Now I need >> to fix this to get a replica in place correctly. >> >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> >> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden >> wrote: >> Shree wrote: >> > OK I thought CA is a part of IPA ? Below is from my master IPA server >> > >> > [root at ldap ~]# ipactl status >> > Directory Service: RUNNING >> > KDC Service: RUNNING >> > KPASSWD Service: RUNNING >> > MEMCACHE Service: RUNNING >> > HTTP Service: RUNNING >> > CA Service: RUNNING >> > [root at ldap ~]# >> > >> > I can certainly send you a log if needed. >> >> It is part of IPA but the IPA server talks to it, not the clients >> directly. >> >> I can only speculate what the client is doing without seeing the log >> files, but I suspect both masters are in DNS and IPA is trying to enroll >> to the initial master which isn't available. >> >> rob >> >> > Shreeraj >> > >> ---------------------------------------------------------------------------------------- >> > >> > >> > Change is the only Constant ! >> > >> > >> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >> > > wrote: >> > Shree wrote: >> > > Peter >> > > Actually I mentioned earlier that my clients are in a separate >> VLAN and >> > > cannot access the master. We have made provisions for the master >> and the >> > > replica to sync by opening the needed ports in the firewall. We have >> > > also opened up ports between the clients and the replica. I have >> tested >> > > the connectivity for these ports. >> > > Perhaps you can tell me if what I am trying to achieve is even >> possible? >> > > i.e >> > > I seem to get stuck with making the replica with the "--setup-ca" >> > > option. Wthout that option I am able to create a replica and have >> it in >> > > sync with the master. However my ipa-client-install fails from >> clients >> > > as they try looking for the master for CA part of the install. >> > >> > Clients don't talk to the CA, they talk to an IPA server which talks to >> > the CA. >> > >> > I think we need to see /var/log/ipaclient-install.log to see what is >> > going on. >> > >> > rob >> > >> > > Shreeraj >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > >> > > >> > > Change is the only Constant ! >> > > >> > > >> > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >> > > >> >> wrote: >> > > On 11.2.2014 23:53, Shree wrote: >> > > >> > > > Following ports are opened between the >> > > > 1) Between the master and the replica (bi directional) >> > > > 2) client machine and the ipa replica (unidirectional). >> > > > When the replica was up it worked fine as far as syncing was >> > concerned. >> > > > >> > > > 80 tcp >> > > > 443 tcp >> > > > 389 tcp >> > > > 636 tcp >> > > > 88 tcp >> > > > 464 tcp >> > > > 88 udp >> > > > 464 udp >> > > > 123 udp >> > > > >> > > > Shreeraj >> > > > >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > > >> > > > Change is the only Constant ! >> > > > >> > > > >> > > > >> > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >> >> > > >> > > >> >>> wrote: >> > > > >> > > > On 02/11/2014 05:05 PM, Shree wrote: >> > > > Dimitri >> > > >> Sorry some the mail landed in my SPAM folder. Let answer your >> > > questions (thanks for your help man) >> > > > Please republish it on the list. >> > > > Do not reply to me directly. >> > > > >> > > > Did you set your first server with the CA? Does all ports that need >> > > > to be open in the firewall between primary or server are >> actually >> > > > open? >> > > > >> > > > >> > > > >> > > >> >> > > >> What I have done so far is uninstalled the replica and tried to >> > > install it again using the "--setup-ca" option. Previously I had >> > > failures and when I removed the "--setup-ca" option the installation >> > > succeeded (in a way). I understand now that I really need to fix >> the CA >> > > installation errors first. >> > > >> >> > > >> >> > > >> 1)The workaround helped me go forward a bit but I got stuck at >> this >> > > point see below >> > > >> =========== >> > > >> [1/3]: creating directory server user >> > > >> [2/3]: creating directory server instance >> > > >> [3/3]: restarting directory server >> > > >> Done configuring directory server for the CA (pkids). >> > > >> ipa : ERROR certmonger failed starting to track >> > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >> > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >> > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >> > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned >> non-zero exit >> > > status 1 >> > > >> Configuring certificate server (pki-cad): Estimated time 3 minutes >> > > 30 seconds >> > > >> [1/17]: creating certificate server user >> > > >> [2/17]: creating pki-ca instance >> > > >> [3/17]: configuring certificate server instance >> > > >> ipa : CRITICAL failed to configure ca instance Command >> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >> > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >> > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >> > > >> =========== >> > > >> 2) No we do not use IPA for a DNS server. >> > > >> >> > > >> >> > > >> 3)The reason for this could be that I had installed the replica >> > > without the "--setup-ca". >> > > >> >> > > >> Shreeraj >> > > >> >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > >> >> > > >> >> > > >> >> > > >> Change is the only Constant ! >> > > >> >> > > >> >> > > >> >> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >> > > > >> > > >> >>> wrote: >> > > >> >> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >> > > >>> Shree wrote: >> > > >>>> Lukas >> > > >>>> Perhaps I should explain the design a bit and >> > > > see if FreeIPA even >> > > >>>> supports this.Our replica is in a separate >> > > > network and all the >> > > >>>> appropriate ports are opened between the master >> > > > and the replica. The >> > > >>>> "replica" got created successfully and is in >> > > > sync with the master >> > > >>>> (except the CA services which I mentioned >> > > > earlier) >> > > >>>> Now,when I try to run ipa-client-install on >> > > > hosts in the new network >> > > >>>> using the replica, it complains that about >> > > > "Cannot contact any KDC for >> > > >>>> realm". >> > > >>>> I am wondering it my hosts in the new network >> > > > are trying to access the >> > > >>>> "master" for certificates since the replica >> > > > does not have any CA >> > > >>>> services running? I couldn't find any obvious >> > > > proof of this even running >> > > >>>> the install in a debug mode. Do I need to open >> > > > ports between the new >> > > >>>> hosts and the master for CA services? >> > > >>>> At this point I cannot disable or move the >> > > > master, it needs to function >> > > >>>> in its location but I need >> > > >>> >> > > >>> No, the clients don't directly talk to the CA. >> > > >>> >> > > >>> You'd need to look in >> > > > /var/log/ipaclient-install.log to see what KDC >> > > >>> was found and we were trying to use. If you have >> > > > SRV records for both >> > > >>> but we try to contact the hidden master this will >> > > > happen. You can try >> > > >>> specifying the server on the command-line with >> > > > --server but this will >> > > >>> be hardcoding things and make it less flexible >> > > > later. >> > > >>> >> > > >>> rob >> > > >>> >> > > >>>> Shreeraj >> > > >>>> >> > > > >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> Change is the only Constant ! >> > > >>>> >> > > >>>> >> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >> > > > Slebodnik >> > > >>>> >> > >> > >> >>> wrote: >> > > >>>> On (06/02/14 18:33), Shree wrote: >> > > >>>> >> > > >>>>> First of all, the ipa-replica-install did >> > > > not allow me to use >> > > >>>> the --setup-ca >> > > >>>>> option complaining that a cert already >> > > > exists, replicate creation was >> > > >>>>> successful after I skipped the option. >> > > >>>>> Seems like the replica is one except >> > > >>>>> 1) There is no CA Service running on the >> > > > replica (which I guess is >> > > >>>> expected) >> > > >>>>> and >> > > >>>>> 2) I am unable to run ipa-client-install >> > > > successfully on any clients >> > > >>>> using >> > > >>>>> the replica. (I don't have the option of >> > > > using the primary master as >> > > >>>> it is >> > > >>>>> configured in a segregated environment. >> > > > Only the master and replica >> > > >>>> are >> > > >>>>> allowed to sync. >> > > >>>>> Debug shows it fails at >> > > >>>>> >> > > >>>>> ipa : DEBUG stderr=kinit: Cannot >> > > > contact any KDC for realm >> > > >>>> 'mydomainname.com' while getting initial >> > > > credentials >> > > >>>> >> > > >>>>> >> > > >>>>> >> > > >>>> >> > > >>>> I was not able to install replica witch CA on >> > > > fedora 20, >> > > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >> > > >>>> >> > > >>>> Guys from dogtag found a workaround >> > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >> > > >>>> >> > > >>>> Does it work for you? >> > > >>>> >> > > >>>> LS >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> _______________________________________________ >> > > >>>> Freeipa-users mailing list >> > > >>>> Freeipa-users at redhat.com >> > >> > >> >> >> > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >>>> >> > > >>> >> > > >>> _______________________________________________ >> > > >>> Freeipa-users mailing list >> > > >>> Freeipa-users at redhat.com >> > >> > >> >> >> > >> > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >> >> > > >> What server provides DNS capabilities to the clients? >> > > >> Do you use IPA DNS or some other DNS? >> > > >> Clients seem to not be able to see replica KDC and try >> > > > to access hidden >> > > >> master but they can know about this master only via DNS. >> > > >> > > >> > > Shree, make sure that command >> > > $ dig -t SRV _kerberos._udp.ipa.example >> > > on the client returns both IPA servers (in ANSWER section). >> > > >> > > -- >> > > Petr^2 Spacek >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Freeipa-users mailing list >> > > Freeipa-users at redhat.com >> > >> > > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >> > >> > >> > >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > I suggest that you temporarily try to install a client in place of the > replica and see why it does not install. > The log above suggests that certmonger that is a part of the replica > fails to connect to the first master. We need to understand the reason > why it fails. Then we would be able to make your replica be a CA. > I suspect that CA related communication between replica and master is > not going through for some reasons. > The install log would be really helpful. > Please see > http://www.freeipa.org/page/Troubleshooting to collect the right logs. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Wed Feb 12 20:49:30 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 12 Feb 2014 22:49:30 +0200 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: <20140212110608.GE19631@localhost.localdomain> References: <52FB357C.8080307@redhat.com> <20140212103224.GK8040@redhat.com> <52FB50DE.1010702@redhat.com> <20140212110608.GE19631@localhost.localdomain> Message-ID: Client's local hostname must match the DNS A record? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Feb 12 20:53:42 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Feb 2014 21:53:42 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FBBDE3.4090102@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> Message-ID: <20140212205342.GR1342@hendrix.redhat.com> On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: > >I don't know it. > >After a quick look I wasn't able to set it up correctly, 'id USER' > >didn't connected to it's socket like with nscd/nlscd, however > >nsswitch.conf was configured. > >Maybe with the upcoming 14.04 or do you have a working howto for 12.04? > > Please check SSSD web site for guidelines and if you have any > questions do not hesitate to ask on the sssd-users list. > SSSD is the best you can get nowadays for the connection of the > client systems to the central identity stores. > If you plan to use it with IPA you ho not need to configure sssd manually. > ipa-client-install will do the trick. Just install ipa-client > package and run the command. If realmd is available for your distribution, then I would highly recommend using it to set up SSSD. From jhrozek at redhat.com Wed Feb 12 20:56:07 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 12 Feb 2014 21:56:07 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FB7F68.9030008@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> Message-ID: <20140212205607.GS1342@hendrix.redhat.com> On Wed, Feb 12, 2014 at 03:04:24PM +0100, Petr Spacek wrote: > >For the records I figured out, that switching from nscd to nslcd did the > >trick. > > BTW why you don't use SSSD? It is packaged for Ubuntu for sure. NSCD > is ... obsolete. SSSD has some very nice features like off-line > cache etc. In all fairness, NSLCD might make sense for users who need support for NSS maps SSSD does not provide (such as networks or hosts) or users who need huge performance for maps for which SSSD doesn't support the fastcache. In those cases, you can configure SSSD for passwd and groups and NSLCD for those SSSD isn't a good fit in your use-case. From shreerajkarulkar at yahoo.com Wed Feb 12 21:29:38 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 13:29:38 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBDCD8.2080800@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> Message-ID: <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> "getcert list" returned a bunch of info, see below root at ldap2 ~]# getcert list Number of certificates and requests being tracked: 2. Request ID '20140206184920': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,...................... ............................. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal wrote: On 02/12/2014 03:41 PM, Shree wrote: So I uninstalled the ipa server and installed the client (ipa-client-install) on the same VM pointing at the master and everything seems to work OK. All the sudo rules etc. Are there any tests I can do check connectivity that could be helpful before I configure this as a "replica" again. Ask certmonger to get a certificate > >? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal wrote: > >On 02/12/2014 02:09 PM, Shree wrote: >Rob >>I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. >> >> >>[1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>?This ended with a? >>Done configuring NTP daemon (ntpd). >>A CA is already configured on this system. >> >> >>[2] So did a pkiremove with the following command >># pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >> >> >> >>[3] Re ran the ipa-replica-install command in step 1 >>The install went a little further but ended below. >> >> >>Configuring directory server for the CA (pkids): Estimated time 30 seconds >>? [1/3]: creating directory server user >>? [2/3]: creating directory server instance >>? [3/3]: restarting directory server >>Done configuring directory server for the CA (pkids). >>ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >>Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >>? [1/17]: creating certificate server user >>? [2/17]: creating pki-ca instance >>? [3/17]: configuring certificate server instance >>ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. >>........................... >>Your system may be partly configured. >>Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >>Configuration of CA failed >> >> >>If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. >> >> >> >> >>Shreeraj >>---------------------------------------------------------------------------------------- >> >> >> >> >>On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: >> >>Shree wrote: >>> OK I thought CA is a part of IPA ? Below is from my master IPA server >>> >>> [root at ldap ~]# ipactl status >>> Directory Service: RUNNING >>> KDC Service: RUNNING >>> KPASSWD Service: RUNNING >>> MEMCACHE Service: RUNNING >>> HTTP Service: RUNNING >>> CA Service: RUNNING >>> [root at ldap ~]# >>> >>> I can certainly send you a log if needed. >> >>It is part of IPA but the IPA server talks to it, not the clients directly. >> >>I can only speculate what the client is doing without seeing the log >>files, but I suspect both masters are in DNS and IPA is trying to enroll >>to the initial master which isn't available. >> >>rob >> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>> wrote: >>> Shree wrote: >>>? > Peter >>>? > Actually I mentioned earlier that my clients are in a separate VLAN and >>>? > cannot access the master. We have made provisions for the master and the >>>? > replica to sync by opening the needed ports in the firewall. We have >>>? > also opened up ports between the clients and the replica. I have tested >>>? > the connectivity for these ports. >>>? > Perhaps you can tell me if what I am trying to achieve is even possible? >>>? > i.e >>>? > I seem to get stuck with making the replica with the "--setup-ca" >>>? > option. Wthout that option I am able to create a replica and have it in >>>? > sync with the master. However my ipa-client-install fails from clients >>>? > as they try looking for the master for CA part of the install. >>> >>> Clients don't talk to the CA, they talk to an IPA server which talks to >>> the CA. >>> >>> I think we need to see /var/log/ipaclient-install.log to see what is >>> going on. >>> >>> rob >>> >>>? > Shreeraj >>>? > >>> ---------------------------------------------------------------------------------------- >>>? > >>>? > >>>? > Change is the only Constant ! >>>? > >>>? > >>>? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>? > > wrote: >>>? > On 11.2.2014 23:53, Shree wrote: >>>? > >>>? >? > Following ports are opened between the >>>? >? > 1) Between the master and the replica (bi directional) >>>? >? > 2) client machine and the ipa replica (unidirectional). >>>? >? > When the replica was up it worked fine as far as syncing was >>> concerned. >>>? >? > >>>? >? >? 80 tcp >>>? >? >? 443 tcp >>>? >? >? 389 tcp >>>? >? >? 636 tcp >>>? >? >? 88 tcp >>>? >? >? 464 tcp >>>? >? >? 88 udp >>>? >? >? 464 udp >>>? >? >? 123 udp >>>? >? > >>>? >? > Shreeraj >>>? >? > >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? > >>>? >? > Change is the only Constant ! >>>? >? > >>>? >? > >>>? >? > >>>? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >> >>>? > >> wrote: >>>? >? > >>>? >? > On 02/11/2014 05:05 PM, Shree wrote: >>>? >? > Dimitri >>>? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >>>? > questions (thanks for your help man) >>>? >? > Please republish it on the list. >>>? >? > Do not reply to me directly. >>>? >? > >>>? >? > Did you set your first server with the CA? Does all ports that need >>>? >? >? ? ? to be open in the firewall between primary or server are actually >>>? >? >? ? ? open? >>>? >? > >>>? >? > >>>? >? > >>>? >? >> >>>? >? >> What I have done so far is uninstalled the replica and tried to >>>? > install it again using the "--setup-ca" option. Previously I had >>>? > failures and when I removed the "--setup-ca" option the installation >>>? > succeeded (in a way). I understand now that I really need to fix the CA >>>? > installation errors first. >>>? >? >> >>>? >? >> >>>? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >>>? > point see below >>>? >? >> =========== >>>? >? >>? ? [1/3]: creating directory server user >>>? >? >>? ? [2/3]: creating directory server instance >>>? >? >>? ? [3/3]: restarting directory server >>>? >? >> Done configuring directory server for the CA (pkids). >>>? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >>>? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >>>? > status 1 >>>? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>? > 30 seconds >>>? >? >>? ? [1/17]: creating certificate server user >>>? >? >>? ? [2/17]: creating pki-ca instance >>>? >? >>? ? [3/17]: configuring certificate server instance >>>? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >>>? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >>>? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>? >? >> =========== >>>? >? >> 2) No we do not use IPA for a DNS server. >>>? >? >> >>>? >? >> >>>? >? >> 3)The reason for this could be that I had installed the replica >>>? > without the "--setup-ca". >>>? >? >> >>>? >? >> Shreeraj >>>? >? >> >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? >> >>>? >? >> >>>? > >> >>>? >? >> Change is the only Constant ! >>>? >? >> >>>? >? >> >>>? >? >> >>>? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>> >>>? > >> wrote: >>>? >? >> >>>? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>? >? >>> Shree wrote: >>>? >? >>>> Lukas >>>? >? >>>> Perhaps I should explain the design a bit and >>>? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >>>? >? >>>> supports this.Our replica is in a separate >>>? >? >? ? ? ? ? ? ? ? ? network and all the >>>? >? >>>> appropriate ports are opened between the master >>>? >? >? ? ? ? ? ? ? ? ? and the replica. The >>>? >? >>>> "replica" got created successfully and is in >>>? >? >? ? ? ? ? ? ? ? ? sync with the master >>>? >? >>>> (except the CA services which I mentioned >>>? >? >? ? ? ? ? ? ? ? ? earlier) >>>? >? >>>> Now,when I try to run ipa-client-install on >>>? >? >? ? hosts in the new network >>>? >? >>>> using the replica, it complains that about >>>? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>>? >? >>>> realm". >>>? >? >>>> I am wondering it my hosts in the new network >>>? >? >? ? ? ? ? ? ? ? ? are trying to access the >>>? >? >>>> "master" for certificates since the replica >>>? >? >? ? ? ? ? ? ? ? ? does not have any CA >>>? >? >>>> services running? I couldn't find any obvious >>>? >? >? ? ? ? ? ? ? ? ? proof of this even running >>>? >? >>>> the install in a debug mode. Do I need to open >>>? >? >? ? ? ? ? ? ? ? ? ports between the new >>>? >? >>>> hosts and the master for CA services? >>>? >? >>>> At this point I cannot disable or? move the >>>? >? >? ? ? ? ? ? ? ? ? master, it needs to function >>>? >? >>>> in its location but I need >>>? >? >>> >>>? >? >>> No, the clients don't directly talk to the CA. >>>? >? >>> >>>? >? >>> You'd need to look in >>>? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>>? >? >>> was found and we were trying to use. If you have >>>? >? >? ? ? ? ? ? ? ? ? SRV records for both >>>? >? >>> but we try to contact the hidden master this will >>>? >? >? ? ? ? ? ? ? ? ? happen. You can try >>>? >? >>> specifying the server on the command-line with >>>? >? >? ? ? ? ? ? ? ? ? --server but this will >>>? >? >>> be hardcoding things and make it less flexible >>>? >? >? ? ? ? ? ? ? ? ? later. >>>? >? >>> >>>? >? >>> rob >>>? >? >>> >>>? >? >>>> Shreeraj >>>? >? >>>> >>>? >? > >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> Change is the only Constant ! >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>? >? >? ? ? ? ? ? ? ? ? Slebodnik >>>? >? >>>> >>> >> wrote: >>>? >? >>>> On (06/02/14 18:33), Shree wrote: >>>? >? >>>> >>>? >? >>>>> First of all, the ipa-replica-install did >>>? >? >? ? ? ? ? ? ? ? ? not allow me to use >>>? >? >>>> the --setup-ca >>>? >? >>>>> option complaining that a cert already >>>? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >>>? >? >>>>> successful after I skipped the option. >>>? >? >>>>> Seems like the replica is one except >>>? >? >>>>> 1) There is no CA Service running on the >>>? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >>>? > >>>> expected) >>>? >? >>>>> and >>>? >? >>>>> 2) I am unable to run ipa-client-install >>>? >? >? ? ? ? ? ? ? ? ? successfully on any clients >>>? >? >>>> using >>>? >? >>>>> the replica. (I don't have the option of >>>? >? >? ? ? ? ? ? ? ? ? using the primary master as >>>? >? >>>> it is >>>? >? >>>>> configured in a segregated environment. >>>? >? >? ? ? ? ? ? ? ? ? Only the master and replica >>>? >? >>>> are >>>? >? >>>>> allowed to sync. >>>? > >>>>> Debug shows it fails at >>>? >? >>>>> >>>? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >>>? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >>>? >? >>>> 'mydomainname.com' while getting initial >>>? >? >? ? ? ? ? ? ? ? ? credentials >>>? >? >>>> >>>? >? >>>>> >>>? >? >>>>> >>>? >? >>>> >>>? >? >>>> I was not able to install replica witch CA on >>>? >? >? ? ? ? ? ? ? ? ? fedora 20, >>>? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>? >? >>>> >>>? >? >>>> Guys from dogtag found a workaround >>>? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>? >? >>>> >>>? >? >>>> Does it work for you? >>>? >? >>>> >>>? >? >>>> LS >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> _______________________________________________ >>>? >? >>>> Freeipa-users mailing list >>>? >? >>>> Freeipa-users at redhat.com >>> > >>>? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>? >? >>>> >>>? >? >>> >>>? >? >>> _______________________________________________ >>>? >? >>> Freeipa-users mailing list >>>? >? >>> Freeipa-users at redhat.com >>> > >>> >>>? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>? >? >> >>>? >? >> What server provides DNS capabilities to the clients? >>>? >? >> Do you use IPA DNS or some other DNS? >>>? >? >> Clients seem to not be able to see replica KDC and try >>>? >? >? ? ? ? ? ? ? ? ? to access hidden >>>? >? >> master but they can know about this master only via DNS. >>>? > >>>? > >>>? > Shree, make sure that command >>>? > $ dig -t SRV _kerberos._udp.ipa.example >>>? > on the client returns both IPA servers (in ANSWER section). >>>? > >>>? > -- >>>? > Petr^2 Spacek >>>? > >>>? > >>>? > >>>? > >>>? > >>>? > _______________________________________________ >>>? > Freeipa-users mailing list >>>? > Freeipa-users at redhat.com >>>? > https://www.redhat.com/mailman/listinfo/freeipa-users >>>? > >>> >>> >>> >> >> >> >> >> >> >>_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. >The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. >I suspect that CA related communication between replica and master is not going through for some reasons. >The install log would be really helpful. >Please see >http://www.freeipa.org/page/Troubleshooting to collect the right logs. > > >-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Wed Feb 12 21:55:13 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 22:55:13 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212205342.GR1342@hendrix.redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <20140212205342.GR1342@hendrix.redhat.com> Message-ID: <52FBEDC1.7060704@martos.bme.hu> On 02/12/2014 09:53 PM, Jakub Hrozek wrote: > On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: >>> I don't know it. >>> After a quick look I wasn't able to set it up correctly, 'id USER' >>> didn't connected to it's socket like with nscd/nlscd, however >>> nsswitch.conf was configured. >>> Maybe with the upcoming 14.04 or do you have a working howto for 12.04? >> Please check SSSD web site for guidelines and if you have any >> questions do not hesitate to ask on the sssd-users list. >> SSSD is the best you can get nowadays for the connection of the >> client systems to the central identity stores. >> If you plan to use it with IPA you ho not need to configure sssd manually. >> ipa-client-install will do the trick. Just install ipa-client >> package and run the command. > If realmd is available for your distribution, then I would highly > recommend using it to set up SSSD. It isn't in 12.04, but will be available in 14.04. Thanks for suggestion. tamas From shreerajkarulkar at yahoo.com Wed Feb 12 21:57:24 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 13:57:24 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> Message-ID: <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> If there aren't any other tests to perform, can I go ahead and uninstall the ipa client and configure this Vm as a replica? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 1:40 PM, Shree wrote: "getcert list" returned a bunch of info, see below root at ldap2 ~]# getcert list Number of certificates and requests being tracked: 2. Request ID '20140206184920': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,...................... ............................. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal wrote: On 02/12/2014 03:41 PM, Shree wrote: So I uninstalled the ipa server and installed the client (ipa-client-install) on the same VM pointing at the master and everything seems to work OK. All the sudo rules etc. Are there any tests I can do check connectivity that could be helpful before I configure this as a "replica" again. Ask certmonger to get a certificate > >? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal wrote: > >On 02/12/2014 02:09 PM, Shree wrote: >Rob >>I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. >> >> >>[1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>?This ended with a? >>Done configuring NTP daemon (ntpd). >>A CA is already configured on this system. >> >> >>[2] So did a pkiremove with the following command >># pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >> >> >> >>[3] Re ran the ipa-replica-install command in step 1 >>The install went a little further but ended below. >> >> >>Configuring directory server for the CA (pkids): Estimated time 30 seconds >>? [1/3]: creating directory server user >>? [2/3]: creating directory server instance >>? [3/3]: restarting directory server >>Done configuring directory server for the CA (pkids). >>ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >>Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >>? [1/17]: creating certificate server user >>? [2/17]: creating pki-ca instance >>? [3/17]: configuring certificate server instance >>ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. >>........................... >>Your system may be partly configured. >>Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >>Configuration of CA failed >> >> >>If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. >> >> >> >> >>Shreeraj >>---------------------------------------------------------------------------------------- >> >> >> >> >>On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: >> >>Shree wrote: >>> OK I thought CA is a part of IPA ? Below is from my master IPA server >>> >>> [root at ldap ~]# ipactl status >>> Directory Service: RUNNING >>> KDC Service: RUNNING >>> KPASSWD Service: RUNNING >>> MEMCACHE Service: RUNNING >>> HTTP Service: RUNNING >>> CA Service: RUNNING >>> [root at ldap ~]# >>> >>> I can certainly send you a log if needed. >> >>It is part of IPA but the IPA server talks to it, not the clients directly. >> >>I can only speculate what the client is doing without seeing the log >>files, but I suspect both masters are in DNS and IPA is trying to enroll >>to the initial master which isn't available. >> >>rob >> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>> wrote: >>> Shree wrote: >>>? > Peter >>>? > Actually I mentioned earlier that my clients are in a separate VLAN and >>>? > cannot access the master. We have made provisions for the master and the >>>? > replica to sync by opening the needed ports in the firewall. We have >>>? > also opened up ports between the clients and the replica. I have tested >>>? > the connectivity for these ports. >>>? > Perhaps you can tell me if what I am trying to achieve is even possible? >>>? > i.e >>>? > I seem to get stuck with making the replica with the "--setup-ca" >>>? > option. Wthout that option I am able to create a replica and have it in >>>? > sync with the master. However my ipa-client-install fails from clients >>>? > as they try looking for the master for CA part of the install. >>> >>> Clients don't talk to the CA, they talk to an IPA server which talks to >>> the CA. >>> >>> I think we need to see /var/log/ipaclient-install.log to see what is >>> going on. >>> >>> rob >>> >>>? > Shreeraj >>>? > >>> ---------------------------------------------------------------------------------------- >>>? > >>>? > >>>? > Change is the only Constant ! >>>? > >>>? > >>>? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>? > > wrote: >>>? > On 11.2.2014 23:53, Shree wrote: >>>? > >>>? >? > Following ports are opened between the >>>? >? > 1) Between the master and the replica (bi directional) >>>? >? > 2) client machine and the ipa replica (unidirectional). >>>? >? > When the replica was up it worked fine as far as syncing was >>> concerned. >>>? >? > >>>? >? >? 80 tcp >>>? >? >? 443 tcp >>>? >? >? 389 tcp >>>? >? >? 636 tcp >>>? >? >? 88 tcp >>>? >? >? 464 tcp >>>? >? >? 88 udp >>>? >? >? 464 udp >>>? >? >? 123 udp >>>? >? > >>>? >? > Shreeraj >>>? >? > >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? > >>>? >? > Change is the only Constant ! >>>? >? > >>>? >? > >>>? >? > >>>? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >> >>>? > >> wrote: >>>? >? > >>>? >? > On 02/11/2014 05:05 PM, Shree wrote: >>>? >? > Dimitri >>>? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >>>? > questions (thanks for your help man) >>>? >? > Please republish it on the list. >>>? >? > Do not reply to me directly. >>>? >? > >>>? >? > Did you set your first server with the CA? Does all ports that need >>>? >? >? ? ? to be open in the firewall between primary or server are actually >>>? >? >? ? ? open? >>>? >? > >>>? >? > >>>? >? > >>>? >? >> >>>? >? >> What I have done so far is uninstalled the replica and tried to >>>? > install it again using the "--setup-ca" option. Previously I had >>>? > failures and when I removed the "--setup-ca" option the installation >>>? > succeeded (in a way). I understand now that I really need to fix the CA >>>? > installation errors first. >>>? >? >> >>>? >? >> >>>? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >>>? > point see below >>>? >? >> =========== >>>? >? >>? ? [1/3]: creating directory server user >>>? >? >>? ? [2/3]: creating directory server instance >>>? >? >>? ? [3/3]: restarting directory server >>>? >? >> Done configuring directory server for the CA (pkids). >>>? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >>>? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >>>? > status 1 >>>? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>? > 30 seconds >>>? >? >>? ? [1/17]: creating certificate server user >>>? >? >>? ? [2/17]: creating pki-ca instance >>>? >? >>? ? [3/17]: configuring certificate server instance >>>? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >>>? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >>>? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>? >? >> =========== >>>? >? >> 2) No we do not use IPA for a DNS server. >>>? >? >> >>>? >? >> >>>? >? >> 3)The reason for this could be that I had installed the replica >>>? > without the "--setup-ca". >>>? >? >> >>>? >? >> Shreeraj >>>? >? >> >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? >> >>>? >? >> >>>? > >> >>>? >? >> Change is the only Constant ! >>>? >? >> >>>? >? >> >>>? >? >> >>>? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>> >>>? > >> wrote: >>>? >? >> >>>? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>? >? >>> Shree wrote: >>>? >? >>>> Lukas >>>? >? >>>> Perhaps I should explain the design a bit and >>>? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >>>? >? >>>> supports this.Our replica is in a separate >>>? >? >? ? ? ? ? ? ? ? ? network and all the >>>? >? >>>> appropriate ports are opened between the master >>>? >? >? ? ? ? ? ? ? ? ? and the replica. The >>>? >? >>>> "replica" got created successfully and is in >>>? >? >? ? ? ? ? ? ? ? ? sync with the master >>>? >? >>>> (except the CA services which I mentioned >>>? >? >? ? ? ? ? ? ? ? ? earlier) >>>? >? >>>> Now,when I try to run ipa-client-install on >>>? >? >? ? hosts in the new network >>>? >? >>>> using the replica, it complains that about >>>? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>>? >? >>>> realm". >>>? >? >>>> I am wondering it my hosts in the new network >>>? >? >? ? ? ? ? ? ? ? ? are trying to access the >>>? >? >>>> "master" for certificates since the replica >>>? >? >? ? ? ? ? ? ? ? ? does not have any CA >>>? >? >>>> services running? I couldn't find any obvious >>>? >? >? ? ? ? ? ? ? ? ? proof of this even running >>>? >? >>>> the install in a debug mode. Do I need to open >>>? >? >? ? ? ? ? ? ? ? ? ports between the new >>>? >? >>>> hosts and the master for CA services? >>>? >? >>>> At this point I cannot disable or? move the >>>? >? >? ? ? ? ? ? ? ? ? master, it needs to function >>>? >? >>>> in its location but I need >>>? >? >>> >>>? >? >>> No, the clients don't directly talk to the CA. >>>? >? >>> >>>? >? >>> You'd need to look in >>>? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>>? >? >>> was found and we were trying to use. If you have >>>? >? >? ? ? ? ? ? ? ? ? SRV records for both >>>? >? >>> but we try to contact the hidden master this will >>>? >? >? ? ? ? ? ? ? ? ? happen. You can try >>>? >? >>> specifying the server on the command-line with >>>? >? >? ? ? ? ? ? ? ? ? --server but this will >>>? >? >>> be hardcoding things and make it less flexible >>>? >? >? ? ? ? ? ? ? ? ? later. >>>? >? >>> >>>? >? >>> rob >>>? >? >>> >>>? >? >>>> Shreeraj >>>? >? >>>> >>>? >? > >>>? > >>> ---------------------------------------------------------------------------------------- >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> Change is the only Constant ! >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>? >? >? ? ? ? ? ? ? ? ? Slebodnik >>>? >? >>>> >>> >> wrote: >>>? >? >>>> On (06/02/14 18:33), Shree wrote: >>>? >? >>>> >>>? >? >>>>> First of all, the ipa-replica-install did >>>? >? >? ? ? ? ? ? ? ? ? not allow me to use >>>? >? >>>> the --setup-ca >>>? >? >>>>> option complaining that a cert already >>>? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >>>? >? >>>>> successful after I skipped the option. >>>? >? >>>>> Seems like the replica is one except >>>? >? >>>>> 1) There is no CA Service running on the >>>? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >>>? > >>>> expected) >>>? >? >>>>> and >>>? >? >>>>> 2) I am unable to run ipa-client-install >>>? >? >? ? ? ? ? ? ? ? ? successfully on any clients >>>? >? >>>> using >>>? >? >>>>> the replica. (I don't have the option of >>>? >? >? ? ? ? ? ? ? ? ? using the primary master as >>>? >? >>>> it is >>>? >? >>>>> configured in a segregated environment. >>>? >? >? ? ? ? ? ? ? ? ? Only the master and replica >>>? >? >>>> are >>>? >? >>>>> allowed to sync. >>>? > >>>>> Debug shows it fails at >>>? >? >>>>> >>>? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >>>? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >>>? >? >>>> 'mydomainname.com' while getting initial >>>? >? >? ? ? ? ? ? ? ? ? credentials >>>? >? >>>> >>>? >? >>>>> >>>? >? >>>>> >>>? >? >>>> >>>? >? >>>> I was not able to install replica witch CA on >>>? >? >? ? ? ? ? ? ? ? ? fedora 20, >>>? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>? >? >>>> >>>? >? >>>> Guys from dogtag found a workaround >>>? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>? >? >>>> >>>? >? >>>> Does it work for you? >>>? >? >>>> >>>? >? >>>> LS >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> >>>? >? >>>> _______________________________________________ >>>? >? >>>> Freeipa-users mailing list >>>? >? >>>> Freeipa-users at redhat.com >>> > >>>? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>? >? >>>> >>>? >? >>> >>>? >? >>> _______________________________________________ >>>? >? >>> Freeipa-users mailing list >>>? >? >>> Freeipa-users at redhat.com >>> > >>> >>>? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>? >? >> >>>? >? >> What server provides DNS capabilities to the clients? >>>? >? >> Do you use IPA DNS or some other DNS? >>>? >? >> Clients seem to not be able to see replica KDC and try >>>? >? >? ? ? ? ? ? ? ? ? to access hidden >>>? >? >> master but they can know about this master only via DNS. >>>? > >>>? > >>>? > Shree, make sure that command >>>? > $ dig -t SRV _kerberos._udp.ipa.example >>>? > on the client returns both IPA servers (in ANSWER section). >>>? > >>>? > -- >>>? > Petr^2 Spacek >>>? > >>>? > >>>? > >>>? > >>>? > >>>? > _______________________________________________ >>>? > Freeipa-users mailing list >>>? > Freeipa-users at redhat.com >>>? > https://www.redhat.com/mailman/listinfo/freeipa-users >>>? > >>> >>> >>> >> >> >> >> >> >> >>_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. >The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. >I suspect that CA related communication between replica and master is not going through for some reasons. >The install log would be really helpful. >Please see >http://www.freeipa.org/page/Troubleshooting to collect the right logs. > > >-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 12 22:29:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Feb 2014 00:29:32 +0200 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FBEDC1.7060704@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <20140212205342.GR1342@hendrix.redhat.com> <52FBEDC1.7060704@martos.bme.hu> Message-ID: <20140212222932.GA11375@redhat.com> On Wed, 12 Feb 2014, Tamas Papp wrote: > >On 02/12/2014 09:53 PM, Jakub Hrozek wrote: >> On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: >>>> I don't know it. >>>> After a quick look I wasn't able to set it up correctly, 'id USER' >>>> didn't connected to it's socket like with nscd/nlscd, however >>>> nsswitch.conf was configured. >>>> Maybe with the upcoming 14.04 or do you have a working howto for 12.04? >>> Please check SSSD web site for guidelines and if you have any >>> questions do not hesitate to ask on the sssd-users list. >>> SSSD is the best you can get nowadays for the connection of the >>> client systems to the central identity stores. >>> If you plan to use it with IPA you ho not need to configure sssd manually. >>> ipa-client-install will do the trick. Just install ipa-client >>> package and run the command. >> If realmd is available for your distribution, then I would highly >> recommend using it to set up SSSD. > >It isn't in 12.04, but will be available in 14.04. >Thanks for suggestion. https://launchpad.net/~sssd/+archive/updates -- / Alexander Bokovoy From abokovoy at redhat.com Wed Feb 12 22:31:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Feb 2014 00:31:50 +0200 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212222932.GA11375@redhat.com> References: <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <20140212205342.GR1342@hendrix.redhat.com> <52FBEDC1.7060704@martos.bme.hu> <20140212222932.GA11375@redhat.com> Message-ID: <20140212223150.GB11375@redhat.com> On Thu, 13 Feb 2014, Alexander Bokovoy wrote: >On Wed, 12 Feb 2014, Tamas Papp wrote: >> >>On 02/12/2014 09:53 PM, Jakub Hrozek wrote: >>>On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: >>>>>I don't know it. >>>>>After a quick look I wasn't able to set it up correctly, 'id USER' >>>>>didn't connected to it's socket like with nscd/nlscd, however >>>>>nsswitch.conf was configured. >>>>>Maybe with the upcoming 14.04 or do you have a working howto for 12.04? >>>>Please check SSSD web site for guidelines and if you have any >>>>questions do not hesitate to ask on the sssd-users list. >>>>SSSD is the best you can get nowadays for the connection of the >>>>client systems to the central identity stores. >>>>If you plan to use it with IPA you ho not need to configure sssd manually. >>>>ipa-client-install will do the trick. Just install ipa-client >>>>package and run the command. >>>If realmd is available for your distribution, then I would highly >>>recommend using it to set up SSSD. >> >>It isn't in 12.04, but will be available in 14.04. >>Thanks for suggestion. >https://launchpad.net/~sssd/+archive/updates Ah, sorry, realmd is indeed not available for 12.04 because it wasn't written at that point yet. :) -- / Alexander Bokovoy From tompos at martos.bme.hu Wed Feb 12 22:31:59 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 23:31:59 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140212222932.GA11375@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <20140212205342.GR1342@hendrix.redhat.com> <52FBEDC1.7060704@martos.bme.hu> <20140212222932.GA11375@redhat.com> Message-ID: <52FBF65F.2030706@martos.bme.hu> On 02/12/2014 11:29 PM, Alexander Bokovoy wrote: > On Wed, 12 Feb 2014, Tamas Papp wrote: >> >> On 02/12/2014 09:53 PM, Jakub Hrozek wrote: >>> On Wed, Feb 12, 2014 at 01:30:59PM -0500, Dmitri Pal wrote: >>>>> I don't know it. >>>>> After a quick look I wasn't able to set it up correctly, 'id USER' >>>>> didn't connected to it's socket like with nscd/nlscd, however >>>>> nsswitch.conf was configured. >>>>> Maybe with the upcoming 14.04 or do you have a working howto for >>>>> 12.04? >>>> Please check SSSD web site for guidelines and if you have any >>>> questions do not hesitate to ask on the sssd-users list. >>>> SSSD is the best you can get nowadays for the connection of the >>>> client systems to the central identity stores. >>>> If you plan to use it with IPA you ho not need to configure sssd >>>> manually. >>>> ipa-client-install will do the trick. Just install ipa-client >>>> package and run the command. >>> If realmd is available for your distribution, then I would highly >>> recommend using it to set up SSSD. >> >> It isn't in 12.04, but will be available in 14.04. >> Thanks for suggestion. > https://launchpad.net/~sssd/+archive/updates I meant realmd is not in 12.04. tamas From tompos at martos.bme.hu Wed Feb 12 22:00:02 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Wed, 12 Feb 2014 23:00:02 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FBBDE3.4090102@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> Message-ID: <52FBEEE2.5060500@martos.bme.hu> On 02/12/2014 07:30 PM, Dmitri Pal wrote: > > Please check SSSD web site for guidelines and if you have any > questions do not hesitate to ask on the sssd-users list. > SSSD is the best you can get nowadays for the connection of the client > systems to the central identity stores. > If you plan to use it with IPA you ho not need to configure sssd > manually. > ipa-client-install will do the trick. Just install ipa-client package > and run the command. It was quite pathetic, when last time I tried on ubuntu. I'll try sssd again, if I have spare time. Thanks, tamas From dpal at redhat.com Wed Feb 12 22:55:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 17:55:22 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> Message-ID: <52FBFBDA.8030104@redhat.com> On 02/12/2014 04:57 PM, Shree wrote: > If there aren't any other tests to perform, can I go ahead and > uninstall the ipa client and configure this Vm as a replica? Thanks for trying. At least we know that certmonger can run by itself. When you install replica please collect all the install logs. Is SELinux on/off? > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 1:40 PM, Shree > wrote: > "getcert list" returned a bunch of info, see below > > root at ldap2 ~]# getcert list > Number of certificates and requests being tracked: 2. > Request ID '20140206184920': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-retrieve-agent-submit > issuer: CN=Certificate Authority,...................... > ............................. > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal > wrote: > On 02/12/2014 03:41 PM, Shree wrote: >> So I uninstalled the ipa server and installed the client >> (ipa-client-install) on the same VM pointing at the master and >> everything seems to work OK. All the sudo rules etc. Are there any >> tests I can do check connectivity that could be helpful before I >> configure this as a "replica" again. > Ask certmonger to get a certificate > >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal >> wrote: >> On 02/12/2014 02:09 PM, Shree wrote: >>> Rob >>> I really appreciate your help, please bear with me. At this point I >>> need to take you back to my ipa-replica-install and what happened >>> there. >>> >>> [1] My command: ipa-replica-install --setup-ca >>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>> This ended with a >>> Done configuring NTP daemon (ntpd). >>> A CA is already configured on this system. >>> >>> [2] So did a pkiremove with the following command >>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>> >>> [3] Re ran the ipa-replica-install command in step 1 >>> The install went a little further but ended below. >>> >>> Configuring directory server for the CA (pkids): Estimated time 30 >>> seconds >>> [1/3]: creating directory server user >>> [2/3]: creating directory server instance >>> [3/3]: restarting directory server >>> Done configuring directory server for the CA (pkids). >>> ipa : ERROR certmonger failed starting to track >>> certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero >>> exit status 1 >>> Configuring certificate server (pki-cad): Estimated time 3 minutes >>> 30 seconds >>> [1/17]: creating certificate server user >>> [2/17]: creating pki-ca instance >>> [3/17]: configuring certificate server instance >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>> ................. >>> ........................... >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Configuration of CA failed >>> >>> If I skip the "--setup-ca" option then the replica gets created >>> without any CA services. The "master" and "replica" are in sync but >>> I am unable to run a ipa-client-install using the replica. Now I >>> need to fix this to get a replica in place correctly. >>> >>> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> >>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden >>> wrote: >>> Shree wrote: >>> > OK I thought CA is a part of IPA ? Below is from my master IPA server >>> > >>> > [root at ldap ~]# ipactl status >>> > Directory Service: RUNNING >>> > KDC Service: RUNNING >>> > KPASSWD Service: RUNNING >>> > MEMCACHE Service: RUNNING >>> > HTTP Service: RUNNING >>> > CA Service: RUNNING >>> > [root at ldap ~]# >>> > >>> > I can certainly send you a log if needed. >>> >>> It is part of IPA but the IPA server talks to it, not the clients >>> directly. >>> >>> I can only speculate what the client is doing without seeing the log >>> files, but I suspect both masters are in DNS and IPA is trying to >>> enroll >>> to the initial master which isn't available. >>> >>> rob >>> >>> > Shreeraj >>> > >>> ---------------------------------------------------------------------------------------- >>> > >>> > >>> > Change is the only Constant ! >>> > >>> > >>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>> > > wrote: >>> > Shree wrote: >>> > > Peter >>> > > Actually I mentioned earlier that my clients are in a separate >>> VLAN and >>> > > cannot access the master. We have made provisions for the master >>> and the >>> > > replica to sync by opening the needed ports in the firewall. We have >>> > > also opened up ports between the clients and the replica. I have >>> tested >>> > > the connectivity for these ports. >>> > > Perhaps you can tell me if what I am trying to achieve is even >>> possible? >>> > > i.e >>> > > I seem to get stuck with making the replica with the "--setup-ca" >>> > > option. Wthout that option I am able to create a replica and >>> have it in >>> > > sync with the master. However my ipa-client-install fails from >>> clients >>> > > as they try looking for the master for CA part of the install. >>> > >>> > Clients don't talk to the CA, they talk to an IPA server which >>> talks to >>> > the CA. >>> > >>> > I think we need to see /var/log/ipaclient-install.log to see what is >>> > going on. >>> > >>> > rob >>> > >>> > > Shreeraj >>> > > >>> > >>> ---------------------------------------------------------------------------------------- >>> > > >>> > > >>> > > Change is the only Constant ! >>> > > >>> > > >>> > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>> > > >>> >> wrote: >>> > > On 11.2.2014 23:53, Shree wrote: >>> > > >>> > > > Following ports are opened between the >>> > > > 1) Between the master and the replica (bi directional) >>> > > > 2) client machine and the ipa replica (unidirectional). >>> > > > When the replica was up it worked fine as far as syncing was >>> > concerned. >>> > > > >>> > > > 80 tcp >>> > > > 443 tcp >>> > > > 389 tcp >>> > > > 636 tcp >>> > > > 88 tcp >>> > > > 464 tcp >>> > > > 88 udp >>> > > > 464 udp >>> > > > 123 udp >>> > > > >>> > > > Shreeraj >>> > > > >>> > > >>> > >>> ---------------------------------------------------------------------------------------- >>> > > > >>> > > > Change is the only Constant ! >>> > > > >>> > > > >>> > > > >>> > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >>> >>> > > >>> > > >>> >>> wrote: >>> > > > >>> > > > On 02/11/2014 05:05 PM, Shree wrote: >>> > > > Dimitri >>> > > >> Sorry some the mail landed in my SPAM folder. Let answer your >>> > > questions (thanks for your help man) >>> > > > Please republish it on the list. >>> > > > Do not reply to me directly. >>> > > > >>> > > > Did you set your first server with the CA? Does all ports that >>> need >>> > > > to be open in the firewall between primary or server are >>> actually >>> > > > open? >>> > > > >>> > > > >>> > > > >>> > > >> >>> > > >> What I have done so far is uninstalled the replica and tried to >>> > > install it again using the "--setup-ca" option. Previously I had >>> > > failures and when I removed the "--setup-ca" option the installation >>> > > succeeded (in a way). I understand now that I really need to fix >>> the CA >>> > > installation errors first. >>> > > >> >>> > > >> >>> > > >> 1)The workaround helped me go forward a bit but I got stuck >>> at this >>> > > point see below >>> > > >> =========== >>> > > >> [1/3]: creating directory server user >>> > > >> [2/3]: creating directory server instance >>> > > >> [3/3]: restarting directory server >>> > > >> Done configuring directory server for the CA (pkids). >>> > > >> ipa : ERROR certmonger failed starting to track >>> > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>> > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>> > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>> > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned >>> non-zero exit >>> > > status 1 >>> > > >> Configuring certificate server (pki-cad): Estimated time 3 >>> minutes >>> > > 30 seconds >>> > > >> [1/17]: creating certificate server user >>> > > >> [2/17]: creating pki-ca instance >>> > > >> [3/17]: configuring certificate server instance >>> > > >> ipa : CRITICAL failed to configure ca instance Command >>> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>> > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir >>> /tmp/tmp-ipJSsT >>> > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>> > > >> =========== >>> > > >> 2) No we do not use IPA for a DNS server. >>> > > >> >>> > > >> >>> > > >> 3)The reason for this could be that I had installed the replica >>> > > without the "--setup-ca". >>> > > >> >>> > > >> Shreeraj >>> > > >> >>> > > >>> > >>> ---------------------------------------------------------------------------------------- >>> > > >> >>> > > >> >>> > > >> >>> > > >> Change is the only Constant ! >>> > > >> >>> > > >> >>> > > >> >>> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>> > >> > >>> > > >>> >>> wrote: >>> > > >> >>> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>> > > >>> Shree wrote: >>> > > >>>> Lukas >>> > > >>>> Perhaps I should explain the design a bit and >>> > > > see if FreeIPA even >>> > > >>>> supports this.Our replica is in a separate >>> > > > network and all the >>> > > >>>> appropriate ports are opened between the master >>> > > > and the replica. The >>> > > >>>> "replica" got created successfully and is in >>> > > > sync with the master >>> > > >>>> (except the CA services which I mentioned >>> > > > earlier) >>> > > >>>> Now,when I try to run ipa-client-install on >>> > > > hosts in the new network >>> > > >>>> using the replica, it complains that about >>> > > > "Cannot contact any KDC for >>> > > >>>> realm". >>> > > >>>> I am wondering it my hosts in the new network >>> > > > are trying to access the >>> > > >>>> "master" for certificates since the replica >>> > > > does not have any CA >>> > > >>>> services running? I couldn't find any obvious >>> > > > proof of this even running >>> > > >>>> the install in a debug mode. Do I need to open >>> > > > ports between the new >>> > > >>>> hosts and the master for CA services? >>> > > >>>> At this point I cannot disable or move the >>> > > > master, it needs to function >>> > > >>>> in its location but I need >>> > > >>> >>> > > >>> No, the clients don't directly talk to the CA. >>> > > >>> >>> > > >>> You'd need to look in >>> > > > /var/log/ipaclient-install.log to see what KDC >>> > > >>> was found and we were trying to use. If you have >>> > > > SRV records for both >>> > > >>> but we try to contact the hidden master this will >>> > > > happen. You can try >>> > > >>> specifying the server on the command-line with >>> > > > --server but this will >>> > > >>> be hardcoding things and make it less flexible >>> > > > later. >>> > > >>> >>> > > >>> rob >>> > > >>> >>> > > >>>> Shreeraj >>> > > >>>> >>> > > > >>> > > >>> > >>> ---------------------------------------------------------------------------------------- >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> Change is the only Constant ! >>> > > >>>> >>> > > >>>> >>> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>> > > > Slebodnik >>> > > >>>> >>> > >>> > >>> >>> wrote: >>> > > >>>> On (06/02/14 18:33), Shree wrote: >>> > > >>>> >>> > > >>>>> First of all, the ipa-replica-install did >>> > > > not allow me to use >>> > > >>>> the --setup-ca >>> > > >>>>> option complaining that a cert already >>> > > > exists, replicate creation was >>> > > >>>>> successful after I skipped the option. >>> > > >>>>> Seems like the replica is one except >>> > > >>>>> 1) There is no CA Service running on the >>> > > > replica (which I guess is >>> > > >>>> expected) >>> > > >>>>> and >>> > > >>>>> 2) I am unable to run ipa-client-install >>> > > > successfully on any clients >>> > > >>>> using >>> > > >>>>> the replica. (I don't have the option of >>> > > > using the primary master as >>> > > >>>> it is >>> > > >>>>> configured in a segregated environment. >>> > > > Only the master and replica >>> > > >>>> are >>> > > >>>>> allowed to sync. >>> > > >>>>> Debug shows it fails at >>> > > >>>>> >>> > > >>>>> ipa : DEBUG stderr=kinit: Cannot >>> > > > contact any KDC for realm >>> > > >>>> 'mydomainname.com' while getting initial >>> > > > credentials >>> > > >>>> >>> > > >>>>> >>> > > >>>>> >>> > > >>>> >>> > > >>>> I was not able to install replica witch CA on >>> > > > fedora 20, >>> > > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>> > > >>>> >>> > > >>>> Guys from dogtag found a workaround >>> > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>> > > >>>> >>> > > >>>> Does it work for you? >>> > > >>>> >>> > > >>>> LS >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> _______________________________________________ >>> > > >>>> Freeipa-users mailing list >>> > > >>>> Freeipa-users at redhat.com >>> > >>> > >>> >> >>> > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> > > >>>> >>> > > >>> >>> > > >>> _______________________________________________ >>> > > >>> Freeipa-users mailing list >>> > > >>> Freeipa-users at redhat.com >>> > >>> > >>> >> >>> > >>> > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> > > >> >>> > > >> What server provides DNS capabilities to the clients? >>> > > >> Do you use IPA DNS or some other DNS? >>> > > >> Clients seem to not be able to see replica KDC and try >>> > > > to access hidden >>> > > >> master but they can know about this master only via DNS. >>> > > >>> > > >>> > > Shree, make sure that command >>> > > $ dig -t SRV _kerberos._udp.ipa.example >>> > > on the client returns both IPA servers (in ANSWER section). >>> > > >>> > > -- >>> > > Petr^2 Spacek >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Freeipa-users mailing list >>> > > Freeipa-users at redhat.com >>> > >>> > > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > > >>> > >>> > >>> > >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> I suggest that you temporarily try to install a client in place of >> the replica and see why it does not install. >> The log above suggests that certmonger that is a part of the replica >> fails to connect to the first master. We need to understand the >> reason why it fails. Then we would be able to make your replica be a CA. >> I suspect that CA related communication between replica and master is >> not going through for some reasons. >> The install log would be really helpful. >> Please see >> http://www.freeipa.org/page/Troubleshooting to collect the right logs. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 12 22:57:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 Feb 2014 17:57:05 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FBEEE2.5060500@martos.bme.hu> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> Message-ID: <52FBFC41.4050200@redhat.com> On 02/12/2014 05:00 PM, Tamas Papp wrote: > On 02/12/2014 07:30 PM, Dmitri Pal wrote: >> Please check SSSD web site for guidelines and if you have any >> questions do not hesitate to ask on the sssd-users list. >> SSSD is the best you can get nowadays for the connection of the client >> systems to the central identity stores. >> If you plan to use it with IPA you ho not need to configure sssd >> manually. >> ipa-client-install will do the trick. Just install ipa-client package >> and run the command. > It was quite pathetic, when last time I tried on ubuntu. > I'll try sssd again, if I have spare time. > > Thanks, > tamas Timo Aaltonen is your man then. ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shreerajkarulkar at yahoo.com Wed Feb 12 23:12:27 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 15:12:27 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBFBDA.8030104@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> Message-ID: <1392246747.45867.YahooMailNeo@web160105.mail.bf1.yahoo.com> It is enforcing. Should I try to disable it? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal wrote: On 02/12/2014 04:57 PM, Shree wrote: If there aren't any other tests to perform, can I go ahead and uninstall the ipa client and configure this Vm as a replica? Thanks for trying. At least we know that certmonger can run by itself. When you install replica please collect all the install logs. Is SELinux on/off? ? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 1:40 PM, Shree wrote: > >"getcert list" returned a bunch of info, see below > > >root at ldap2 ~]# getcert list >Number of certificates and requests being tracked: 2. >Request ID '20140206184920': >status: MONITORING >stuck: no >key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >CA: dogtag-ipa-retrieve-agent-submit >issuer: CN=Certificate Authority,...................... >............................. > > >? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal wrote: > >On 02/12/2014 03:41 PM, Shree wrote: >So I uninstalled the ipa server and installed the client (ipa-client-install) on the same VM pointing at the master and everything seems to work OK. All the sudo rules etc. Are there any tests I can do check connectivity that could be helpful before I configure this as a "replica" again. Ask certmonger to get a certificate > > > >> >>? >>Shreeraj >>---------------------------------------------------------------------------------------- >> >>Change is the only Constant ! >> >> >> >>On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal wrote: >> >>On 02/12/2014 02:09 PM, Shree wrote: >>Rob >>>I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. >>> >>> >>>[1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>>?This ended with a? >>>Done configuring NTP daemon (ntpd). >>>A CA is already configured on this system. >>> >>> >>>[2] So did a pkiremove with the following command >>># pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>> >>> >>> >>>[3] Re ran the ipa-replica-install command in step 1 >>>The install went a little further but ended below. >>> >>> >>>Configuring directory server for the CA (pkids): Estimated time 30 seconds >>>? [1/3]: creating directory server user >>>? [2/3]: creating directory server instance >>>? [3/3]: restarting directory server >>>Done configuring directory server for the CA (pkids). >>>ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >>>Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >>>? [1/17]: creating certificate server user >>>? [2/17]: creating pki-ca instance >>>? [3/17]: configuring certificate server instance >>>ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. >>>........................... >>>Your system may be partly configured. >>>Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> >>>Configuration of CA failed >>> >>> >>>If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. >>> >>> >>> >>> >>>Shreeraj >>>---------------------------------------------------------------------------------------- >>> >>> >>> >>> >>>On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: >>> >>>Shree wrote: >>>> OK I thought CA is a part of IPA ? Below is from my master IPA server >>>> >>>> [root at ldap ~]# ipactl status >>>> Directory Service: RUNNING >>>> KDC Service: RUNNING >>>> KPASSWD Service: RUNNING >>>> MEMCACHE Service: RUNNING >>>> HTTP Service: RUNNING >>>> CA Service: RUNNING >>>> [root at ldap ~]# >>>> >>>> I can certainly send you a log if needed. >>> >>>It is part of IPA but the IPA server talks to it, not the clients directly. >>> >>>I can only speculate what the client is doing without seeing the log >>>files, but I suspect both masters are in DNS and IPA is trying to enroll >>>to the initial master which isn't available. >>> >>>rob >>> >>>> Shreeraj >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> Change is the only Constant ! >>>> >>>> >>>> On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>>> wrote: >>>> Shree wrote: >>>>? > Peter >>>>? > Actually I mentioned earlier that my clients are in a separate VLAN and >>>>? > cannot access the master. We have made provisions for the master and the >>>>? > replica to sync by opening the needed ports in the firewall. We have >>>>? > also opened up ports between the clients and the replica. I have tested >>>>? > the connectivity for these ports. >>>>? > Perhaps you can tell me if what I am trying to achieve is even possible? >>>>? > i.e >>>>? > I seem to get stuck with making the replica with the "--setup-ca" >>>>? > option. Wthout that option I am able to create a replica and have it in >>>>? > sync with the master. However my ipa-client-install fails from clients >>>>? > as they try looking for the master for CA part of the install. >>>> >>>> Clients don't talk to the CA, they talk to an IPA server which talks to >>>> the CA. >>>> >>>> I think we need to see /var/log/ipaclient-install.log to see what is >>>> going on. >>>> >>>> rob >>>> >>>>? > Shreeraj >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? > >>>>? > >>>>? > Change is the only Constant ! >>>>? > >>>>? > >>>>? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>>? > > wrote: >>>>? > On 11.2.2014 23:53, Shree wrote: >>>>? > >>>>? >? > Following ports are opened between the >>>>? >? > 1) Between the master and the replica (bi directional) >>>>? >? > 2) client machine and the ipa replica (unidirectional). >>>>? >? > When the replica was up it worked fine as far as syncing was >>>> concerned. >>>>? >? > >>>>? >? >? 80 tcp >>>>? >? >? 443 tcp >>>>? >? >? 389 tcp >>>>? >? >? 636 tcp >>>>? >? >? 88 tcp >>>>? >? >? 464 tcp >>>>? >? >? 88 udp >>>>? >? >? 464 udp >>>>? >? >? 123 udp >>>>? >? > >>>>? >? > Shreeraj >>>>? >? > >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? > >>>>? >? > Change is the only Constant ! >>>>? >? > >>>>? >? > >>>>? >? > >>>>? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >>> >>>>? > >> wrote: >>>>? >? > >>>>? >? > On 02/11/2014 05:05 PM, Shree wrote: >>>>? >? > Dimitri >>>>? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >>>>? > questions (thanks for your help man) >>>>? >? > Please republish it on the list. >>>>? >? > Do not reply to me directly. >>>>? >? > >>>>? >? > Did you set your first server with the CA? Does all ports that need >>>>? >? >? ? ? to be open in the firewall between primary or server are actually >>>>? >? >? ? ? open? >>>>? >? > >>>>? >? > >>>>? >? > >>>>? >? >> >>>>? >? >> What I have done so far is uninstalled the replica and tried to >>>>? > install it again using the "--setup-ca" option. Previously I had >>>>? > failures and when I removed the "--setup-ca" option the installation >>>>? > succeeded (in a way). I understand now that I really need to fix the CA >>>>? > installation errors first. >>>>? >? >> >>>>? >? >> >>>>? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >>>>? > point see below >>>>? >? >> =========== >>>>? >? >>? ? [1/3]: creating directory server user >>>>? >? >>? ? [2/3]: creating directory server instance >>>>? >? >>? ? [3/3]: restarting directory server >>>>? >? >> Done configuring directory server for the CA (pkids). >>>>? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >>>>? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>>? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>>? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>>? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >>>>? > status 1 >>>>? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>>? > 30 seconds >>>>? >? >>? ? [1/17]: creating certificate server user >>>>? >? >>? ? [2/17]: creating pki-ca instance >>>>? >? >>? ? [3/17]: configuring certificate server instance >>>>? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >>>>? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>>? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >>>>? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>>? >? >> =========== >>>>? >? >> 2) No we do not use IPA for a DNS server. >>>>? >? >> >>>>? >? >> >>>>? >? >> 3)The reason for this could be that I had installed the replica >>>>? > without the "--setup-ca". >>>>? >? >> >>>>? >? >> Shreeraj >>>>? >? >> >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? >> >>>>? >? >> >>>>? > >> >>>>? >? >> Change is the only Constant ! >>>>? >? >> >>>>? >? >> >>>>? >? >> >>>>? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>>> >>>>? > >> wrote: >>>>? >? >> >>>>? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>>? >? >>> Shree wrote: >>>>? >? >>>> Lukas >>>>? >? >>>> Perhaps I should explain the design a bit and >>>>? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >>>>? >? >>>> supports this.Our replica is in a separate >>>>? >? >? ? ? ? ? ? ? ? ? network and all the >>>>? >? >>>> appropriate ports are opened between the master >>>>? >? >? ? ? ? ? ? ? ? ? and the replica. The >>>>? >? >>>> "replica" got created successfully and is in >>>>? >? >? ? ? ? ? ? ? ? ? sync with the master >>>>? >? >>>> (except the CA services which I mentioned >>>>? >? >? ? ? ? ? ? ? ? ? earlier) >>>>? >? >>>> Now,when I try to run ipa-client-install on >>>>? >? >? ? hosts in the new network >>>>? >? >>>> using the replica, it complains that about >>>>? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>>>? >? >>>> realm". >>>>? >? >>>> I am wondering it my hosts in the new network >>>>? >? >? ? ? ? ? ? ? ? ? are trying to access the >>>>? >? >>>> "master" for certificates since the replica >>>>? >? >? ? ? ? ? ? ? ? ? does not have any CA >>>>? >? >>>> services running? I couldn't find any obvious >>>>? >? >? ? ? ? ? ? ? ? ? proof of this even running >>>>? >? >>>> the install in a debug mode. Do I need to open >>>>? >? >? ? ? ? ? ? ? ? ? ports between the new >>>>? >? >>>> hosts and the master for CA services? >>>>? >? >>>> At this point I cannot disable or? move the >>>>? >? >? ? ? ? ? ? ? ? ? master, it needs to function >>>>? >? >>>> in its location but I need >>>>? >? >>> >>>>? >? >>> No, the clients don't directly talk to the CA. >>>>? >? >>> >>>>? >? >>> You'd need to look in >>>>? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>>>? >? >>> was found and we were trying to use. If you have >>>>? >? >? ? ? ? ? ? ? ? ? SRV records for both >>>>? >? >>> but we try to contact the hidden master this will >>>>? >? >? ? ? ? ? ? ? ? ? happen. You can try >>>>? >? >>> specifying the server on the command-line with >>>>? >? >? ? ? ? ? ? ? ? ? --server but this will >>>>? >? >>> be hardcoding things and make it less flexible >>>>? >? >? ? ? ? ? ? ? ? ? later. >>>>? >? >>> >>>>? >? >>> rob >>>>? >? >>> >>>>? >? >>>> Shreeraj >>>>? >? >>>> >>>>? >? > >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> Change is the only Constant ! >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>>? >? >? ? ? ? ? ? ? ? ? Slebodnik >>>>? >? >>>> >>>> >> wrote: >>>>? >? >>>> On (06/02/14 18:33), Shree wrote: >>>>? >? >>>> >>>>? >? >>>>> First of all, the ipa-replica-install did >>>>? >? >? ? ? ? ? ? ? ? ? not allow me to use >>>>? >? >>>> the --setup-ca >>>>? >? >>>>> option complaining that a cert already >>>>? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >>>>? >? >>>>> successful after I skipped the option. >>>>? >? >>>>> Seems like the replica is one except >>>>? >? >>>>> 1) There is no CA Service running on the >>>>? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >>>>? > >>>> expected) >>>>? >? >>>>> and >>>>? >? >>>>> 2) I am unable to run ipa-client-install >>>>? >? >? ? ? ? ? ? ? ? ? successfully on any clients >>>>? >? >>>> using >>>>? >? >>>>> the replica. (I don't have the option of >>>>? >? >? ? ? ? ? ? ? ? ? using the primary master as >>>>? >? >>>> it is >>>>? >? >>>>> configured in a segregated environment. >>>>? >? >? ? ? ? ? ? ? ? ? Only the master and replica >>>>? >? >>>> are >>>>? >? >>>>> allowed to sync. >>>>? > >>>>> Debug shows it fails at >>>>? >? >>>>> >>>>? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >>>>? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >>>>? >? >>>> 'mydomainname.com' while getting initial >>>>? >? >? ? ? ? ? ? ? ? ? credentials >>>>? >? >>>> >>>>? >? >>>>> >>>>? >? >>>>> >>>>? >? >>>> >>>>? >? >>>> I was not able to install replica witch CA on >>>>? >? >? ? ? ? ? ? ? ? ? fedora 20, >>>>? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>>? >? >>>> >>>>? >? >>>> Guys from dogtag found a workaround >>>>? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>>? >? >>>> >>>>? >? >>>> Does it work for you? >>>>? >? >>>> >>>>? >? >>>> LS >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> _______________________________________________ >>>>? >? >>>> Freeipa-users mailing list >>>>? >? >>>> Freeipa-users at redhat.com >>>> > >>>>? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? >? >>>> >>>>? >? >>> >>>>? >? >>> _______________________________________________ >>>>? >? >>> Freeipa-users mailing list >>>>? >? >>> Freeipa-users at redhat.com >>>> > >>>> >>>>? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? >? >> >>>>? >? >> What server provides DNS capabilities to the clients? >>>>? >? >> Do you use IPA DNS or some other DNS? >>>>? >? >> Clients seem to not be able to see replica KDC and try >>>>? >? >? ? ? ? ? ? ? ? ? to access hidden >>>>? >? >> master but they can know about this master only via DNS. >>>>? > >>>>? > >>>>? > Shree, make sure that command >>>>? > $ dig -t SRV _kerberos._udp.ipa.example >>>>? > on the client returns both IPA servers (in ANSWER section). >>>>? > >>>>? > -- >>>>? > Petr^2 Spacek >>>>? > >>>>? > >>>>? > >>>>? > >>>>? > >>>>? > _______________________________________________ >>>>? > Freeipa-users mailing list >>>>? > Freeipa-users at redhat.com >>>>? > https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? > >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. >>The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. >>I suspect that CA related communication between replica and master is not going through for some reasons. >>The install log would be really helpful. >>Please see >>http://www.freeipa.org/page/Troubleshooting to collect the right logs. >> >> >>-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >> >>_______________________________________________ >>Freeipa-users mailing list >>Freeipa-users at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > >-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ > > > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Wed Feb 12 23:18:42 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 12 Feb 2014 15:18:42 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FBFBDA.8030104@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> Message-ID: <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yahoo.com> Ok, failed at the same stage, would you like the entire /var/log/ipareplica-install.log. If yes, should I attach to the email? pa???????? : INFO?????? File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script ??? return_value = main_function() ? File "/usr/sbin/ipa-replica-install", line 467, in main ??? (CA, cs) = cainstance.install_replica_ca(config) ? File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1604, in install_replica_ca ??? subject_base=config.subject_base) ? File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 617, in configure_instance ??? self.start_creation(runtime=210) ? File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation ??? method() ? File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 879, in __configure_instance ??? raise RuntimeError('Configuration of CA failed') ipa???????? : INFO???? The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed [root at ldap2 ~]# ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal wrote: On 02/12/2014 04:57 PM, Shree wrote: If there aren't any other tests to perform, can I go ahead and uninstall the ipa client and configure this Vm as a replica? Thanks for trying. At least we know that certmonger can run by itself. When you install replica please collect all the install logs. Is SELinux on/off? ? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 1:40 PM, Shree wrote: > >"getcert list" returned a bunch of info, see below > > >root at ldap2 ~]# getcert list >Number of certificates and requests being tracked: 2. >Request ID '20140206184920': >status: MONITORING >stuck: no >key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >CA: dogtag-ipa-retrieve-agent-submit >issuer: CN=Certificate Authority,...................... >............................. > > >? >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal wrote: > >On 02/12/2014 03:41 PM, Shree wrote: >So I uninstalled the ipa server and installed the client (ipa-client-install) on the same VM pointing at the master and everything seems to work OK. All the sudo rules etc. Are there any tests I can do check connectivity that could be helpful before I configure this as a "replica" again. Ask certmonger to get a certificate > > > >> >>? >>Shreeraj >>---------------------------------------------------------------------------------------- >> >>Change is the only Constant ! >> >> >> >>On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal wrote: >> >>On 02/12/2014 02:09 PM, Shree wrote: >>Rob >>>I really appreciate your help, please bear with me. At this point I need to take you back to my ?ipa-replica-install and what happened there. >>> >>> >>>[1] My command:?ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>>?This ended with a? >>>Done configuring NTP daemon (ntpd). >>>A CA is already configured on this system. >>> >>> >>>[2] So did a pkiremove with the following command >>># pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>> >>> >>> >>>[3] Re ran the ipa-replica-install command in step 1 >>>The install went a little further but ended below. >>> >>> >>>Configuring directory server for the CA (pkids): Estimated time 30 seconds >>>? [1/3]: creating directory server user >>>? [2/3]: creating directory server instance >>>? [3/3]: restarting directory server >>>Done configuring directory server for the CA (pkids). >>>ipa ? ? ? ? : ERROR ? ?certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 >>>Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds >>>? [1/17]: creating certificate server user >>>? [2/17]: creating pki-ca instance >>>? [3/17]: configuring certificate server instance >>>ipa ? ? ? ? : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ................. >>>........................... >>>Your system may be partly configured. >>>Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> >>>Configuration of CA failed >>> >>> >>>If I skip the "--setup-ca" option then the replica gets created without any CA services. The "master" and "replica" are in sync but I am unable to run a ipa-client-install using ?the replica. Now I need to fix this to get a replica in place correctly. >>> >>> >>> >>> >>>Shreeraj >>>---------------------------------------------------------------------------------------- >>> >>> >>> >>> >>>On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden wrote: >>> >>>Shree wrote: >>>> OK I thought CA is a part of IPA ? Below is from my master IPA server >>>> >>>> [root at ldap ~]# ipactl status >>>> Directory Service: RUNNING >>>> KDC Service: RUNNING >>>> KPASSWD Service: RUNNING >>>> MEMCACHE Service: RUNNING >>>> HTTP Service: RUNNING >>>> CA Service: RUNNING >>>> [root at ldap ~]# >>>> >>>> I can certainly send you a log if needed. >>> >>>It is part of IPA but the IPA server talks to it, not the clients directly. >>> >>>I can only speculate what the client is doing without seeing the log >>>files, but I suspect both masters are in DNS and IPA is trying to enroll >>>to the initial master which isn't available. >>> >>>rob >>> >>>> Shreeraj >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> Change is the only Constant ! >>>> >>>> >>>> On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>>> wrote: >>>> Shree wrote: >>>>? > Peter >>>>? > Actually I mentioned earlier that my clients are in a separate VLAN and >>>>? > cannot access the master. We have made provisions for the master and the >>>>? > replica to sync by opening the needed ports in the firewall. We have >>>>? > also opened up ports between the clients and the replica. I have tested >>>>? > the connectivity for these ports. >>>>? > Perhaps you can tell me if what I am trying to achieve is even possible? >>>>? > i.e >>>>? > I seem to get stuck with making the replica with the "--setup-ca" >>>>? > option. Wthout that option I am able to create a replica and have it in >>>>? > sync with the master. However my ipa-client-install fails from clients >>>>? > as they try looking for the master for CA part of the install. >>>> >>>> Clients don't talk to the CA, they talk to an IPA server which talks to >>>> the CA. >>>> >>>> I think we need to see /var/log/ipaclient-install.log to see what is >>>> going on. >>>> >>>> rob >>>> >>>>? > Shreeraj >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? > >>>>? > >>>>? > Change is the only Constant ! >>>>? > >>>>? > >>>>? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>>? > > wrote: >>>>? > On 11.2.2014 23:53, Shree wrote: >>>>? > >>>>? >? > Following ports are opened between the >>>>? >? > 1) Between the master and the replica (bi directional) >>>>? >? > 2) client machine and the ipa replica (unidirectional). >>>>? >? > When the replica was up it worked fine as far as syncing was >>>> concerned. >>>>? >? > >>>>? >? >? 80 tcp >>>>? >? >? 443 tcp >>>>? >? >? 389 tcp >>>>? >? >? 636 tcp >>>>? >? >? 88 tcp >>>>? >? >? 464 tcp >>>>? >? >? 88 udp >>>>? >? >? 464 udp >>>>? >? >? 123 udp >>>>? >? > >>>>? >? > Shreeraj >>>>? >? > >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? > >>>>? >? > Change is the only Constant ! >>>>? >? > >>>>? >? > >>>>? >? > >>>>? >? > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >>> >>>>? > >> wrote: >>>>? >? > >>>>? >? > On 02/11/2014 05:05 PM, Shree wrote: >>>>? >? > Dimitri >>>>? >? >> Sorry some the mail landed in my SPAM folder. Let answer your >>>>? > questions (thanks for your help man) >>>>? >? > Please republish it on the list. >>>>? >? > Do not reply to me directly. >>>>? >? > >>>>? >? > Did you set your first server with the CA? Does all ports that need >>>>? >? >? ? ? to be open in the firewall between primary or server are actually >>>>? >? >? ? ? open? >>>>? >? > >>>>? >? > >>>>? >? > >>>>? >? >> >>>>? >? >> What I have done so far is uninstalled the replica and tried to >>>>? > install it again using the "--setup-ca" option. Previously I had >>>>? > failures and when I removed the "--setup-ca" option the installation >>>>? > succeeded (in a way). I understand now that I really need to fix the CA >>>>? > installation errors first. >>>>? >? >> >>>>? >? >> >>>>? >? >> 1)The workaround helped me go forward a bit but I got stuck at this >>>>? > point see below >>>>? >? >> =========== >>>>? >? >>? ? [1/3]: creating directory server user >>>>? >? >>? ? [2/3]: creating directory server instance >>>>? >? >>? ? [3/3]: restarting directory server >>>>? >? >> Done configuring directory server for the CA (pkids). >>>>? >? >> ipa? ? ? ? : ERROR? ? certmonger failed starting to track >>>>? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>>? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>>? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>>? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit >>>>? > status 1 >>>>? >? >> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>>? > 30 seconds >>>>? >? >>? ? [1/17]: creating certificate server user >>>>? >? >>? ? [2/17]: creating pki-ca instance >>>>? >? >>? ? [3/17]: configuring certificate server instance >>>>? >? >> ipa? ? ? ? : CRITICAL failed to configure ca instance Command >>>>? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>>? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT >>>>? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>>? >? >> =========== >>>>? >? >> 2) No we do not use IPA for a DNS server. >>>>? >? >> >>>>? >? >> >>>>? >? >> 3)The reason for this could be that I had installed the replica >>>>? > without the "--setup-ca". >>>>? >? >> >>>>? >? >> Shreeraj >>>>? >? >> >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? >> >>>>? >? >> >>>>? > >> >>>>? >? >> Change is the only Constant ! >>>>? >? >> >>>>? >? >> >>>>? >? >> >>>>? >? >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>>> >>>>? > >> wrote: >>>>? >? >> >>>>? >? >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>>? >? >>> Shree wrote: >>>>? >? >>>> Lukas >>>>? >? >>>> Perhaps I should explain the design a bit and >>>>? >? >? ? ? ? ? ? ? ? ? see if FreeIPA even >>>>? >? >>>> supports this.Our replica is in a separate >>>>? >? >? ? ? ? ? ? ? ? ? network and all the >>>>? >? >>>> appropriate ports are opened between the master >>>>? >? >? ? ? ? ? ? ? ? ? and the replica. The >>>>? >? >>>> "replica" got created successfully and is in >>>>? >? >? ? ? ? ? ? ? ? ? sync with the master >>>>? >? >>>> (except the CA services which I mentioned >>>>? >? >? ? ? ? ? ? ? ? ? earlier) >>>>? >? >>>> Now,when I try to run ipa-client-install on >>>>? >? >? ? hosts in the new network >>>>? >? >>>> using the replica, it complains that about >>>>? >? >? ? ? ? ? ? ? ? ? "Cannot contact any KDC for >>>>? >? >>>> realm". >>>>? >? >>>> I am wondering it my hosts in the new network >>>>? >? >? ? ? ? ? ? ? ? ? are trying to access the >>>>? >? >>>> "master" for certificates since the replica >>>>? >? >? ? ? ? ? ? ? ? ? does not have any CA >>>>? >? >>>> services running? I couldn't find any obvious >>>>? >? >? ? ? ? ? ? ? ? ? proof of this even running >>>>? >? >>>> the install in a debug mode. Do I need to open >>>>? >? >? ? ? ? ? ? ? ? ? ports between the new >>>>? >? >>>> hosts and the master for CA services? >>>>? >? >>>> At this point I cannot disable or? move the >>>>? >? >? ? ? ? ? ? ? ? ? master, it needs to function >>>>? >? >>>> in its location but I need >>>>? >? >>> >>>>? >? >>> No, the clients don't directly talk to the CA. >>>>? >? >>> >>>>? >? >>> You'd need to look in >>>>? >? >? ? ? ? ? ? ? ? ? /var/log/ipaclient-install.log to see what KDC >>>>? >? >>> was found and we were trying to use. If you have >>>>? >? >? ? ? ? ? ? ? ? ? SRV records for both >>>>? >? >>> but we try to contact the hidden master this will >>>>? >? >? ? ? ? ? ? ? ? ? happen. You can try >>>>? >? >>> specifying the server on the command-line with >>>>? >? >? ? ? ? ? ? ? ? ? --server but this will >>>>? >? >>> be hardcoding things and make it less flexible >>>>? >? >? ? ? ? ? ? ? ? ? later. >>>>? >? >>> >>>>? >? >>> rob >>>>? >? >>> >>>>? >? >>>> Shreeraj >>>>? >? >>>> >>>>? >? > >>>>? > >>>> ---------------------------------------------------------------------------------------- >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> Change is the only Constant ! >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>>? >? >? ? ? ? ? ? ? ? ? Slebodnik >>>>? >? >>>> >>>> >> wrote: >>>>? >? >>>> On (06/02/14 18:33), Shree wrote: >>>>? >? >>>> >>>>? >? >>>>> First of all, the ipa-replica-install did >>>>? >? >? ? ? ? ? ? ? ? ? not allow me to use >>>>? >? >>>> the --setup-ca >>>>? >? >>>>> option complaining that a cert already >>>>? >? >? ? ? ? ? ? ? ? ? exists, replicate creation was >>>>? >? >>>>> successful after I skipped the option. >>>>? >? >>>>> Seems like the replica is one except >>>>? >? >>>>> 1) There is no CA Service running on the >>>>? >? >? ? ? ? ? ? ? ? ? replica (which I guess is >>>>? > >>>> expected) >>>>? >? >>>>> and >>>>? >? >>>>> 2) I am unable to run ipa-client-install >>>>? >? >? ? ? ? ? ? ? ? ? successfully on any clients >>>>? >? >>>> using >>>>? >? >>>>> the replica. (I don't have the option of >>>>? >? >? ? ? ? ? ? ? ? ? using the primary master as >>>>? >? >>>> it is >>>>? >? >>>>> configured in a segregated environment. >>>>? >? >? ? ? ? ? ? ? ? ? Only the master and replica >>>>? >? >>>> are >>>>? >? >>>>> allowed to sync. >>>>? > >>>>> Debug shows it fails at >>>>? >? >>>>> >>>>? >? >>>>> ipa? ? ? ? : DEBUG? ? stderr=kinit: Cannot >>>>? >? >? ? ? ? ? ? ? ? ? contact any KDC for realm >>>>? >? >>>> 'mydomainname.com' while getting initial >>>>? >? >? ? ? ? ? ? ? ? ? credentials >>>>? >? >>>> >>>>? >? >>>>> >>>>? >? >>>>> >>>>? >? >>>> >>>>? >? >>>> I was not able to install replica witch CA on >>>>? >? >? ? ? ? ? ? ? ? ? fedora 20, >>>>? >? >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816 >>>>? >? >>>> >>>>? >? >>>> Guys from dogtag found a workaround >>>>? >? >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>>? >? >>>> >>>>? >? >>>> Does it work for you? >>>>? >? >>>> >>>>? >? >>>> LS >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> >>>>? >? >>>> _______________________________________________ >>>>? >? >>>> Freeipa-users mailing list >>>>? >? >>>> Freeipa-users at redhat.com >>>> > >>>>? >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? >? >>>> >>>>? >? >>> >>>>? >? >>> _______________________________________________ >>>>? >? >>> Freeipa-users mailing list >>>>? >? >>> Freeipa-users at redhat.com >>>> > >>>> >>>>? >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? >? >> >>>>? >? >> What server provides DNS capabilities to the clients? >>>>? >? >> Do you use IPA DNS or some other DNS? >>>>? >? >> Clients seem to not be able to see replica KDC and try >>>>? >? >? ? ? ? ? ? ? ? ? to access hidden >>>>? >? >> master but they can know about this master only via DNS. >>>>? > >>>>? > >>>>? > Shree, make sure that command >>>>? > $ dig -t SRV _kerberos._udp.ipa.example >>>>? > on the client returns both IPA servers (in ANSWER section). >>>>? > >>>>? > -- >>>>? > Petr^2 Spacek >>>>? > >>>>? > >>>>? > >>>>? > >>>>? > >>>>? > _______________________________________________ >>>>? > Freeipa-users mailing list >>>>? > Freeipa-users at redhat.com >>>>? > https://www.redhat.com/mailman/listinfo/freeipa-users >>>>? > >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I suggest that you temporarily try to install a client in place of the replica and see why it does not install. >>The log above suggests that certmonger that is a part of the replica fails to connect to the first master. We need to understand the reason why it fails. Then we would be able to make your replica be a CA. >>I suspect that CA related communication between replica and master is not going through for some reasons. >>The install log would be really helpful. >>Please see >>http://www.freeipa.org/page/Troubleshooting to collect the right logs. >> >> >>-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >> >>_______________________________________________ >>Freeipa-users mailing list >>Freeipa-users at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > >-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ > > > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Wed Feb 12 23:35:58 2014 From: mail at willsheldon.com (Will Sheldon) Date: Wed, 12 Feb 2014 15:35:58 -0800 Subject: [Freeipa-users] authentication against compat In-Reply-To: <52FBFC41.4050200@redhat.com> References: <52FB62F0.7060607@martos.bme.hu> <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> Message-ID: <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> Is SSSD working for IPA sudo now? I saw this From Jakub Horozek in this list a little while back: Unfortunately with 6.5 there is still no sudo ipa provider, there might be with one in 6.6. So in order to download the sudo rules you need to configure the LDAP sudo provider manually. Will. On Wednesday, February 12, 2014 at 2:57 PM, Dmitri Pal wrote: > On 02/12/2014 05:00 PM, Tamas Papp wrote: > > On 02/12/2014 07:30 PM, Dmitri Pal wrote: > > > Please check SSSD web site for guidelines and if you have any > > > questions do not hesitate to ask on the sssd-users list. > > > SSSD is the best you can get nowadays for the connection of the client > > > systems to the central identity stores. > > > If you plan to use it with IPA you ho not need to configure sssd > > > manually. > > > ipa-client-install will do the trick. Just install ipa-client package > > > and run the command. > > > > > > > It was quite pathetic, when last time I tried on ubuntu. > > I'll try sssd again, if I have spare time. > > > > Thanks, > > tamas > > > > Timo Aaltonen is your man then. ;-) > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ (http://www.redhat.com/carveoutcosts/) > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Thu Feb 13 00:13:57 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Thu, 13 Feb 2014 00:13:57 +0000 Subject: [Freeipa-users] trouble creating a replica in the cloud In-Reply-To: <52FBBF1F.4060106@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> <52FBB92B.4070606@redhat.com>,<52FBBF1F.4060106@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E2272428@EXCHMB1-ELS.BWINC.local> thanks Guys, turns out this was a redhat bug in the 6.4 image of the aws instance, so I built in 6.5 and was able to get past it, but now I'm failing with this: Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: ObjectclassViolation: missing attribute "idnsSOAserial" required by object class "idnsZone" i tried attaching the log file but unfortunately its 30 mb trying to compress ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, February 12, 2014 10:36 AM To: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] trouble creating a replica in the cloud Dmitri Pal wrote: > On 02/11/2014 05:02 PM, Todd Maugh wrote: >> Hey Guys, >> >> So I have my master and replica up in my datacenter. >> >> I have a client, I have a winsync agreement, I have a password sync. >> >> It's working lovely. >> >> So Now I have spun up an AWS instance of redh hat 6.5 (same as my >> master and first replica) >> >> I run the ipa replica and it fails >> >> >> ipa-replica-install --setup-ca --setup-dns --no-forwarders >> /var/lib/ipa/replica-info-se-idm-03.boingo.com.gpg >> Directory Manager (existing master) password: >> >> Run connection check to master >> Check connection from replica to remote master 'se-idm-01.boingo.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 >> PKI-CA: Directory Service port (7389): 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 BOINGO.COM password: >> >> Execute check on remote master >> Check connection from master to remote replica 'se-idm-03.boingo.com': >> 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 >> PKI-CA: Directory Service port (7389): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> 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 for the CA (pkids): Estimated time 30 seconds >> [1/3]: creating directory server user >> [2/3]: creating directory server instance >> ipa : CRITICAL failed to create ds instance Command >> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3' >> returned non-zero exit status 1 >> [3/3]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server. See the >> installation log for details. >> Done configuring directory server for the CA (pkids). >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> Can't contact LDAP server >> >> >> I check the log file and this is what I get >> >> 2014-02-11T19:55:48Z DEBUG calling setup-ds.pl >> 2014-02-11T19:57:53Z DEBUG args=/usr/sbin/setup-ds.pl --silent >> --logfile - -f /tmp/tmpo9ROF3 >> 2014-02-11T19:57:53Z DEBUG stdout=[11/Feb/2014:14:57:53 -0500] >> createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: >> Netscape Portable Runtime error -5966 (Access Denied.) >> [11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All >> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >> (Access Denied.) >> [14/02/11:14:57:53] - [Setup] Info Could not start the directory >> server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. >> The last line from the error log was '[11/Feb/2014:14:57:53 -0500] create >> prlistensockets - PR_Bind() on All Interfaces port 7389 failed: >> Netscape Portable Runtime error -5966 (Access Denied.) >> '. Error: Unknown error 256 >> Could not start the directory server using command >> '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the >> error log was '[11/Feb/2014:14:57:53 -0500] createprlistensockets - >> PR_Bind() on All >> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >> (Access Denied.) >> '. Error: Unknown error 256 >> [14/02/11:14:57:53] - [Setup] Fatal Error: Could not create directory >> server instance 'PKI-IPA'. >> Error: Could not create directory server instance 'PKI-IPA'. >> [14/02/11:14:57:53] - [Setup] Fatal Exiting . . . >> Log file is '-' >> >> Exiting . . . >> Log file is '-' >> >> >> >> >> Please help >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Bind failed. This usually happens when the system has an identity crisis > and tries to bind to the interface that is not there. Access Denied is a bit unexpected though it may have to do with the AWS network config. Any SELinux errors or anything in /var/log/messages? Running IPA in AWS is a bit strange because of the dynamic nature of AWS. Have you seen http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Thu Feb 13 07:29:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Feb 2014 08:29:38 +0100 Subject: [Freeipa-users] Choosing the right way to create trust In-Reply-To: References: <52FB357C.8080307@redhat.com> <20140212103224.GK8040@redhat.com> <52FB50DE.1010702@redhat.com> <20140212110608.GE19631@localhost.localdomain> Message-ID: <52FC7462.6060207@redhat.com> On 12.2.2014 21:49, Genadi Postrilko wrote: > Client's local hostname must match the DNS A record? I would recommend you to try it and report results. We can't be sure what will happen (in Kerberos libraries and applications) until you try that. -- Petr^2 Spacek From pspacek at redhat.com Thu Feb 13 08:13:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Feb 2014 09:13:42 +0100 Subject: [Freeipa-users] trouble creating a replica in the cloud In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2272428@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2270E40@EXCHMB1-ELS.BWINC.local> <52FBB92B.4070606@redhat.com>, <52FBBF1F.4060106@redhat.com> <6FB698E172A95F49BE009B36D56F53E2272428@EXCHMB1-ELS.BWINC.local> Message-ID: <52FC7EB6.4020308@redhat.com> On 13.2.2014 01:13, Todd Maugh wrote: > thanks Guys, turns out this was a redhat bug in the 6.4 image of the aws instance, so I built in 6.5 > > and was able to get past it, but now I'm failing with this: > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-install.log for details: > ObjectclassViolation: missing attribute "idnsSOAserial" required by object class "idnsZone" > > i tried attaching the log file but unfortunately its 30 mb trying to compress That is interesting. Which version of ipa-server package you are trying to install? Is it RHEL or CentOS 6.5? My guess that you have DNS installed on one IPA server and now you are installing another replica without DNS (without --setup-dns option), right? May be that you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=894131 but it was fixed in ipa-3.0.0-22.el6. Petr^2 Spacek > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] > Sent: Wednesday, February 12, 2014 10:36 AM > To: dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] trouble creating a replica in the cloud > > Dmitri Pal wrote: >> On 02/11/2014 05:02 PM, Todd Maugh wrote: >>> Hey Guys, >>> >>> So I have my master and replica up in my datacenter. >>> >>> I have a client, I have a winsync agreement, I have a password sync. >>> >>> It's working lovely. >>> >>> So Now I have spun up an AWS instance of redh hat 6.5 (same as my >>> master and first replica) >>> >>> I run the ipa replica and it fails >>> >>> >>> ipa-replica-install --setup-ca --setup-dns --no-forwarders >>> /var/lib/ipa/replica-info-se-idm-03.boingo.com.gpg >>> Directory Manager (existing master) password: >>> >>> Run connection check to master >>> Check connection from replica to remote master 'se-idm-01.boingo.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 >>> PKI-CA: Directory Service port (7389): 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 BOINGO.COM password: >>> >>> Execute check on remote master >>> Check connection from master to remote replica 'se-idm-03.boingo.com': >>> 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 >>> PKI-CA: Directory Service port (7389): OK >>> >>> Connection from master to replica is OK. >>> >>> Connection check OK >>> 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 for the CA (pkids): Estimated time 30 seconds >>> [1/3]: creating directory server user >>> [2/3]: creating directory server instance >>> ipa : CRITICAL failed to create ds instance Command >>> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpo9ROF3' >>> returned non-zero exit status 1 >>> [3/3]: restarting directory server >>> ipa : CRITICAL Failed to restart the directory server. See the >>> installation log for details. >>> Done configuring directory server for the CA (pkids). >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> Can't contact LDAP server >>> >>> >>> I check the log file and this is what I get >>> >>> 2014-02-11T19:55:48Z DEBUG calling setup-ds.pl >>> 2014-02-11T19:57:53Z DEBUG args=/usr/sbin/setup-ds.pl --silent >>> --logfile - -f /tmp/tmpo9ROF3 >>> 2014-02-11T19:57:53Z DEBUG stdout=[11/Feb/2014:14:57:53 -0500] >>> createprlistensockets - PR_Bind() on All Interfaces port 7389 failed: >>> Netscape Portable Runtime error -5966 (Access Denied.) >>> [11/Feb/2014:14:57:53 -0500] createprlistensockets - PR_Bind() on All >>> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >>> (Access Denied.) >>> [14/02/11:14:57:53] - [Setup] Info Could not start the directory >>> server using command '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. >>> The last line from the error log was '[11/Feb/2014:14:57:53 -0500] create >>> prlistensockets - PR_Bind() on All Interfaces port 7389 failed: >>> Netscape Portable Runtime error -5966 (Access Denied.) >>> '. Error: Unknown error 256 >>> Could not start the directory server using command >>> '/usr/lib64/dirsrv/slapd-PKI-IPA/start-slapd'. The last line from the >>> error log was '[11/Feb/2014:14:57:53 -0500] createprlistensockets - >>> PR_Bind() on All >>> Interfaces port 7389 failed: Netscape Portable Runtime error -5966 >>> (Access Denied.) >>> '. Error: Unknown error 256 >>> [14/02/11:14:57:53] - [Setup] Fatal Error: Could not create directory >>> server instance 'PKI-IPA'. >>> Error: Could not create directory server instance 'PKI-IPA'. >>> [14/02/11:14:57:53] - [Setup] Fatal Exiting . . . >>> Log file is '-' >>> >>> Exiting . . . >>> Log file is '-' >>> >>> Please help >> >> Bind failed. This usually happens when the system has an identity crisis >> and tries to bind to the interface that is not there. > > Access Denied is a bit unexpected though it may have to do with the AWS > network config. Any SELinux errors or anything in /var/log/messages? > > Running IPA in AWS is a bit strange because of the dynamic nature of > AWS. Have you seen > http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html > > rob From mkosek at redhat.com Thu Feb 13 08:31:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Feb 2014 09:31:34 +0100 Subject: [Freeipa-users] SELinux user categories In-Reply-To: References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> <52FBD782.6080903@redhat.com> Message-ID: <52FC82E6.6050902@redhat.com> On 02/12/2014 09:33 PM, Josh wrote: > > On Feb 12, 2014, at 3:20 PM, Rob Crittenden wrote: > >> Josh wrote: >>> >>> On Feb 11, 2014, at 2:52 PM, Rob Crittenden wrote: >>> >>>> Josh wrote: >>>>> >>>>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >>>> > wrote: >>>>> >>>>>> Josh wrote: >>>>>>> I have a situation where I need to support more than 1024 categories >>>>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>>>> number of categories I need but ipa still responds with the original >>>>>>> error message. Do I need to restart any of the services? >>>>>>> >>>>>>> Here is the command that was run and the output after applying the >>>>>>> patch below: >>>>>>> >>>>>>> ipa config-mod >>>>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>>>> >>>>>> Have you updated your SELinux policy to support a larger MCS range? If >>>>>> not then this will get you past the IPA validator but it won't work >>>>>> with SELinux. See semanage(8). >>>>>> >>>>>> rob >>>>> >>>>> Yes. I?m trying to set the SELinux categories in freeipa because when >>>>> you have lots of categories all semanage commands slow down (way down). >>>>> For other people?s knowledge, this requires recompilation of the >>>>> SELinux policy. >>>> >>>> Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. >>> >>> As it is for a very unique situation which most people won?t encounter I don?t think it?s worth making configurable. >>>> >>>> Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. >>> >>> I?m ok with that because the values only need to be set during initial setup. Any idea why the validator isn?t being modified? >>>> >>>> I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. >>>> >>>> regards >>>> >>>> rob >>>> >>> >>> Thanks for the help. >> >> Sure. I'm glad we made at least obvious enough for you to be able to work around. >> >> So I'm just curious about the need for this. You mentioned that semanage slows way down. Have you talked to the SELinux team about this? They've been quite responsive to our needs in the past, they may be able to fix something for you as well. > > I?m not sure if my coworker has talked to them about it directly, no. I?ll ping him to see if it?s something we want to get worked on moving forward. >> >> On a more general note, we haven't had a lot of user feedback on the SELinux user map feature. Do you have any other suggestions on things we might do to improve it? > > Nothing directly but I can describe how we?re using it and where some of the perceived pain points are. Their impact is negligible though so we haven?t felt the need to investigate better ways to work around them. > > We?ve got a network of systems running both targeted and MLS SELinux policy. What this means is that we must define both valid selinux context is the user map. I.e. we define both staff_u:s0-s0:c0.c1023 and staff_u:s0-s15:c0.c1023 in the user map. We then use host groups and multiple user maps to map appropriately. Our commands might be easier to understand: > > ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$staff_u:s0-s15:c0.c1023? > ipa hostgroup-add mls --desc="MLS SELinux Group? > ipa hostgroup-add-member mls --hosts=mlshost1,mlshost2 > ipa hostgroup-add targeted --desc="Targeted SELinux Group? > ipa hostgroup-add-member targeted --hosts=appsrv1,appsrv2 > ipa selinuxusermap-add staff_u --selinuxuser=staff_u:s0-s0:c0.c1023 > ipa selinuxusermap-add staff_u_MLS --selinuxuser=staff_u:s0-s15:c0.c1023 > ipa selinuxusermap-add-host staff_u --hostgroups=targeted > ipa selinuxusermap-add-host staff_u_MLS --hostgroups=mls > ipa selinuxusermap-add-user staff_u --groups=wheel > ipa selinuxusermap-add-user staff_u_MLS --groups=wheel > > It might be more straightforward if we didn?t have to split the configuration like this but thanks to the flexibility of FreeIPA it?s very easy to do. > > Thanks, > -josh Nice. Not many of our users got back to us with experience on using the advanced use of the SELinux feature - so feedback welcome! Rob, I am wondering if it would make sense to extend the FreeIPA to allow SELinux user map rules with more SELinux users, per policy? I.e. have a rule like that: # ipa selinuxusermap-show staff_u Rule name: staff_u SELinux User: staff_u:s0-s0:c0.c1023 SELinux User (mls): staff_u:s0-s15:c0.c1023 Enabled: TRUE User Groups: wheel Host Groups: selinuxhosts This proposed rule structure is not ideal and would require updated IPA&SSSD on all machines but it should explain the idea. Martin From jhrozek at redhat.com Thu Feb 13 08:46:37 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 13 Feb 2014 09:46:37 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> References: <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> Message-ID: <20140213084637.GF1342@hendrix.redhat.com> On Wed, Feb 12, 2014 at 03:35:58PM -0800, Will Sheldon wrote: > Is SSSD working for IPA sudo now? It was working even before, just with a bit of manual config, as I said in the reply you quoted, you just had to configure 'sudo_provider=ldap' > I saw this From Jakub Horozek in this list a little while back: > > Unfortunately with 6.5 there is still no sudo ipa provider, there might > be with one in 6.6. So in order to download the sudo rules you need to > configure the LDAP sudo provider manually. sudo_provider=ipa is included in 1.9.6 and also all recent versions (1.11.x) We're thinking about including a newer version in RHEL-6.6, where the sudo_provider=ipa would be included as well. From rcritten at redhat.com Thu Feb 13 14:41:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 09:41:49 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! oo.com> Message-ID: <52FCD9AD.5000502@redhat.com> Shree wrote: > Ok, failed at the same stage, would you like the entire > /var/log/ipareplica-install.log. If yes, should I attach to the email? > > > > pa : INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 467, in main > (CA, cs) = cainstance.install_replica_ca(config) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 1604, in install_replica_ca > subject_base=config.subject_base) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 617, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 879, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > ipa : INFO The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > [root at ldap2 ~]# > We need to see the full /var/log/ipareplica-install.log and the debug log from /var/log/pki-ca. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal wrote: > On 02/12/2014 04:57 PM, Shree wrote: >> If there aren't any other tests to perform, can I go ahead and >> uninstall the ipa client and configure this Vm as a replica? > > Thanks for trying. At least we know that certmonger can run by itself. > When you install replica please collect all the install logs. > Is SELinux on/off? > >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 1:40 PM, Shree >> wrote: >> "getcert list" returned a bunch of info, see below >> >> root at ldap2 ~]# getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20140206184920': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,...................... >> ............................. >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal >> wrote: >> On 02/12/2014 03:41 PM, Shree wrote: >>> So I uninstalled the ipa server and installed the client >>> (ipa-client-install) on the same VM pointing at the master and >>> everything seems to work OK. All the sudo rules etc. Are there any >>> tests I can do check connectivity that could be helpful before I >>> configure this as a "replica" again. >> Ask certmonger to get a certificate >> >>> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal >>> wrote: >>> On 02/12/2014 02:09 PM, Shree wrote: >>>> Rob >>>> I really appreciate your help, please bear with me. At this point I >>>> need to take you back to my ipa-replica-install and what happened >>>> there. >>>> >>>> [1] My command: ipa-replica-install --setup-ca >>>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>>> This ended with a >>>> Done configuring NTP daemon (ntpd). >>>> A CA is already configured on this system. >>>> >>>> [2] So did a pkiremove with the following command >>>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>>> >>>> [3] Re ran the ipa-replica-install command in step 1 >>>> The install went a little further but ended below. >>>> >>>> Configuring directory server for the CA (pkids): Estimated time 30 >>>> seconds >>>> [1/3]: creating directory server user >>>> [2/3]: creating directory server instance >>>> [3/3]: restarting directory server >>>> Done configuring directory server for the CA (pkids). >>>> ipa : ERROR certmonger failed starting to track certificate: >>>> Command '/usr/bin/ipa-getcert start-tracking -d >>>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero >>>> exit status 1 >>>> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>> 30 seconds >>>> [1/17]: creating certificate server user >>>> [2/17]: creating pki-ca instance >>>> [3/17]: configuring certificate server instance >>>> ipa : CRITICAL failed to configure ca instance Command >>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>> ................. >>>> ........................... >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Configuration of CA failed >>>> >>>> If I skip the "--setup-ca" option then the replica gets created >>>> without any CA services. The "master" and "replica" are in sync but >>>> I am unable to run a ipa-client-install using the replica. Now I >>>> need to fix this to get a replica in place correctly. >>>> >>>> >>>> Shreeraj >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden >>>> wrote: >>>> Shree wrote: >>>> > OK I thought CA is a part of IPA ? Below is from my master IPA server >>>> > >>>> > [root at ldap ~]# ipactl status >>>> > Directory Service: RUNNING >>>> > KDC Service: RUNNING >>>> > KPASSWD Service: RUNNING >>>> > MEMCACHE Service: RUNNING >>>> > HTTP Service: RUNNING >>>> > CA Service: RUNNING >>>> > [root at ldap ~]# >>>> > >>>> > I can certainly send you a log if needed. >>>> >>>> It is part of IPA but the IPA server talks to it, not the clients >>>> directly. >>>> >>>> I can only speculate what the client is doing without seeing the log >>>> files, but I suspect both masters are in DNS and IPA is trying to >>>> enroll >>>> to the initial master which isn't available. >>>> >>>> rob >>>> >>>> > Shreeraj >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > >>>> > >>>> > Change is the only Constant ! >>>> > >>>> > >>>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>>> > > wrote: >>>> > Shree wrote: >>>> > > Peter >>>> > > Actually I mentioned earlier that my clients are in a separate >>>> VLAN and >>>> > > cannot access the master. We have made provisions for the >>>> master and the >>>> > > replica to sync by opening the needed ports in the firewall. We >>>> have >>>> > > also opened up ports between the clients and the replica. I >>>> have tested >>>> > > the connectivity for these ports. >>>> > > Perhaps you can tell me if what I am trying to achieve is even >>>> possible? >>>> > > i.e >>>> > > I seem to get stuck with making the replica with the "--setup-ca" >>>> > > option. Wthout that option I am able to create a replica and >>>> have it in >>>> > > sync with the master. However my ipa-client-install fails from >>>> clients >>>> > > as they try looking for the master for CA part of the install. >>>> > >>>> > Clients don't talk to the CA, they talk to an IPA server which >>>> talks to >>>> > the CA. >>>> > >>>> > I think we need to see /var/log/ipaclient-install.log to see what is >>>> > going on. >>>> > >>>> > rob >>>> > >>>> > > Shreeraj >>>> > > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > > >>>> > > >>>> > > Change is the only Constant ! >>>> > > >>>> > > >>>> > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>> > > >>>> >> wrote: >>>> > > On 11.2.2014 23:53, Shree wrote: >>>> > > >>>> > > > Following ports are opened between the >>>> > > > 1) Between the master and the replica (bi directional) >>>> > > > 2) client machine and the ipa replica (unidirectional). >>>> > > > When the replica was up it worked fine as far as syncing was >>>> > concerned. >>>> > > > >>>> > > > 80 tcp >>>> > > > 443 tcp >>>> > > > 389 tcp >>>> > > > 636 tcp >>>> > > > 88 tcp >>>> > > > 464 tcp >>>> > > > 88 udp >>>> > > > 464 udp >>>> > > > 123 udp >>>> > > > >>>> > > > Shreeraj >>>> > > > >>>> > > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > > > >>>> > > > Change is the only Constant ! >>>> > > > >>>> > > > >>>> > > > >>>> > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >>>> >>>> > > >>>> > > >>>> >>> wrote: >>>> > > > >>>> > > > On 02/11/2014 05:05 PM, Shree wrote: >>>> > > > Dimitri >>>> > > >> Sorry some the mail landed in my SPAM folder. Let answer your >>>> > > questions (thanks for your help man) >>>> > > > Please republish it on the list. >>>> > > > Do not reply to me directly. >>>> > > > >>>> > > > Did you set your first server with the CA? Does all ports >>>> that need >>>> > > > to be open in the firewall between primary or server are >>>> actually >>>> > > > open? >>>> > > > >>>> > > > >>>> > > > >>>> > > >> >>>> > > >> What I have done so far is uninstalled the replica and tried to >>>> > > install it again using the "--setup-ca" option. Previously I had >>>> > > failures and when I removed the "--setup-ca" option the >>>> installation >>>> > > succeeded (in a way). I understand now that I really need to >>>> fix the CA >>>> > > installation errors first. >>>> > > >> >>>> > > >> >>>> > > >> 1)The workaround helped me go forward a bit but I got stuck >>>> at this >>>> > > point see below >>>> > > >> =========== >>>> > > >> [1/3]: creating directory server user >>>> > > >> [2/3]: creating directory server instance >>>> > > >> [3/3]: restarting directory server >>>> > > >> Done configuring directory server for the CA (pkids). >>>> > > >> ipa : ERROR certmonger failed starting to track >>>> > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>> > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>> > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>> > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned >>>> non-zero exit >>>> > > status 1 >>>> > > >> Configuring certificate server (pki-cad): Estimated time 3 >>>> minutes >>>> > > 30 seconds >>>> > > >> [1/17]: creating certificate server user >>>> > > >> [2/17]: creating pki-ca instance >>>> > > >> [3/17]: configuring certificate server instance >>>> > > >> ipa : CRITICAL failed to configure ca instance Command >>>> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>> > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir >>>> /tmp/tmp-ipJSsT >>>> > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>> > > >> =========== >>>> > > >> 2) No we do not use IPA for a DNS server. >>>> > > >> >>>> > > >> >>>> > > >> 3)The reason for this could be that I had installed the replica >>>> > > without the "--setup-ca". >>>> > > >> >>>> > > >> Shreeraj >>>> > > >> >>>> > > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> Change is the only Constant ! >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>>> > >>> > >>>> > > >>>> >>> wrote: >>>> > > >> >>>> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>> > > >>> Shree wrote: >>>> > > >>>> Lukas >>>> > > >>>> Perhaps I should explain the design a bit and >>>> > > > see if FreeIPA even >>>> > > >>>> supports this.Our replica is in a separate >>>> > > > network and all the >>>> > > >>>> appropriate ports are opened between the master >>>> > > > and the replica. The >>>> > > >>>> "replica" got created successfully and is in >>>> > > > sync with the master >>>> > > >>>> (except the CA services which I mentioned >>>> > > > earlier) >>>> > > >>>> Now,when I try to run ipa-client-install on >>>> > > > hosts in the new network >>>> > > >>>> using the replica, it complains that about >>>> > > > "Cannot contact any KDC for >>>> > > >>>> realm". >>>> > > >>>> I am wondering it my hosts in the new network >>>> > > > are trying to access the >>>> > > >>>> "master" for certificates since the replica >>>> > > > does not have any CA >>>> > > >>>> services running? I couldn't find any obvious >>>> > > > proof of this even running >>>> > > >>>> the install in a debug mode. Do I need to open >>>> > > > ports between the new >>>> > > >>>> hosts and the master for CA services? >>>> > > >>>> At this point I cannot disable or move the >>>> > > > master, it needs to function >>>> > > >>>> in its location but I need >>>> > > >>> >>>> > > >>> No, the clients don't directly talk to the CA. >>>> > > >>> >>>> > > >>> You'd need to look in >>>> > > > /var/log/ipaclient-install.log to see what KDC >>>> > > >>> was found and we were trying to use. If you have >>>> > > > SRV records for both >>>> > > >>> but we try to contact the hidden master this will >>>> > > > happen. You can try >>>> > > >>> specifying the server on the command-line with >>>> > > > --server but this will >>>> > > >>> be hardcoding things and make it less flexible >>>> > > > later. >>>> > > >>> >>>> > > >>> rob >>>> > > >>> >>>> > > >>>> Shreeraj >>>> > > >>>> >>>> > > > >>>> > > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> Change is the only Constant ! >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>> > > > Slebodnik >>>> > > >>>> >>>> > >>>> > >>>> >>> wrote: >>>> > > >>>> On (06/02/14 18:33), Shree wrote: >>>> > > >>>> >>>> > > >>>>> First of all, the ipa-replica-install did >>>> > > > not allow me to use >>>> > > >>>> the --setup-ca >>>> > > >>>>> option complaining that a cert already >>>> > > > exists, replicate creation was >>>> > > >>>>> successful after I skipped the option. >>>> > > >>>>> Seems like the replica is one except >>>> > > >>>>> 1) There is no CA Service running on the >>>> > > > replica (which I guess is >>>> > > >>>> expected) >>>> > > >>>>> and >>>> > > >>>>> 2) I am unable to run ipa-client-install >>>> > > > successfully on any clients >>>> > > >>>> using >>>> > > >>>>> the replica. (I don't have the option of >>>> > > > using the primary master as >>>> > > >>>> it is >>>> > > >>>>> configured in a segregated environment. >>>> > > > Only the master and replica >>>> > > >>>> are >>>> > > >>>>> allowed to sync. >>>> > > >>>>> Debug shows it fails at >>>> > > >>>>> >>>> > > >>>>> ipa : DEBUG stderr=kinit: Cannot >>>> > > > contact any KDC for realm >>>> > > >>>> 'mydomainname.com' while getting initial >>>> > > > credentials >>>> > > >>>> >>>> > > >>>>> >>>> > > >>>>> >>>> > > >>>> >>>> > > >>>> I was not able to install replica witch CA on >>>> > > > fedora 20, >>>> > > >>>> Bug is already reported >>>> https://fedorahosted.org/pki/ticket/816 >>>> > > >>>> >>>> > > >>>> Guys from dogtag found a workaround >>>> > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>> > > >>>> >>>> > > >>>> Does it work for you? >>>> > > >>>> >>>> > > >>>> LS >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> _______________________________________________ >>>> > > >>>> Freeipa-users mailing list >>>> > > >>>> Freeipa-users at redhat.com >>>> > >>>> > >>>> >> >>>> > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > > >>>> >>>> > > >>> >>>> > > >>> _______________________________________________ >>>> > > >>> Freeipa-users mailing list >>>> > > >>> Freeipa-users at redhat.com >>>> > >>>> > >>>> >> >>>> > >>>> > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > > >> >>>> > > >> What server provides DNS capabilities to the clients? >>>> > > >> Do you use IPA DNS or some other DNS? >>>> > > >> Clients seem to not be able to see replica KDC and try >>>> > > > to access hidden >>>> > > >> master but they can know about this master only via DNS. >>>> > > >>>> > > >>>> > > Shree, make sure that command >>>> > > $ dig -t SRV _kerberos._udp.ipa.example >>>> > > on the client returns both IPA servers (in ANSWER section). >>>> > > >>>> > > -- >>>> > > Petr^2 Spacek >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > Freeipa-users mailing list >>>> > > Freeipa-users at redhat.com >>>> > >>>> > > https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > > >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> I suggest that you temporarily try to install a client in place of >>> the replica and see why it does not install. >>> The log above suggests that certmonger that is a part of the replica >>> fails to connect to the first master. We need to understand the >>> reason why it fails. Then we would be able to make your replica be a CA. >>> I suspect that CA related communication between replica and master is >>> not going through for some reasons. >>> The install log would be really helpful. >>> Please see >>> http://www.freeipa.org/page/Troubleshooting to collect the right logs. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Thu Feb 13 14:47:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 09:47:53 -0500 Subject: [Freeipa-users] SELinux user categories In-Reply-To: <52FC82E6.6050902@redhat.com> References: <384125AE-F5B6-4DF2-9BF6-894CF9061CA9@gmail.com> <52FA7DB7.3070402@redhat.com> <52FA7F83.1070709@redhat.com> <21214AF2-B271-44F4-A2BD-832E87240EB2@gmail.com> <52FBD782.6080903@redhat.com> <52FC82E6.6050902@redhat.com> Message-ID: <52FCDB19.9020609@redhat.com> Martin Kosek wrote: > On 02/12/2014 09:33 PM, Josh wrote: >> >> On Feb 12, 2014, at 3:20 PM, Rob Crittenden wrote: >> >>> Josh wrote: >>>> >>>> On Feb 11, 2014, at 2:52 PM, Rob Crittenden wrote: >>>> >>>>> Josh wrote: >>>>>> >>>>>> On Feb 11, 2014, at 2:44 PM, Rob Crittenden >>>>> > wrote: >>>>>> >>>>>>> Josh wrote: >>>>>>>> I have a situation where I need to support more than 1024 categories >>>>>>>> on a system. I modified the selinuxusermap.py file to check for the >>>>>>>> number of categories I need but ipa still responds with the original >>>>>>>> error message. Do I need to restart any of the services? >>>>>>>> >>>>>>>> Here is the command that was run and the output after applying the >>>>>>>> patch below: >>>>>>>> >>>>>>>> ipa config-mod >>>>>>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s15:c0.c16383$resadm_u:s0-s15:c0.c16383$ia_u:s0-s15:c0.c16383' >>>>>>>> ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user >>>>>>>> 'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must >>>>>>>> match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123] >>>>>>> >>>>>>> Have you updated your SELinux policy to support a larger MCS range? If >>>>>>> not then this will get you past the IPA validator but it won't work >>>>>>> with SELinux. See semanage(8). >>>>>>> >>>>>>> rob >>>>>> >>>>>> Yes. I?m trying to set the SELinux categories in freeipa because when >>>>>> you have lots of categories all semanage commands slow down (way down). >>>>>> For other people?s knowledge, this requires recompilation of the >>>>>> SELinux policy. >>>>> >>>>> Ok, then your patch looks reasonable. The current code is for the default values and we haven't had cause to make this configurable before now. You might consider filing a ticket in our trac about this. >>>> >>>> As it is for a very unique situation which most people won?t encounter I don?t think it?s worth making configurable. >>>>> >>>>> Also note that this change will be lost on your next IPA upgrade, and you'll need to make this change on any IPA master you want these values to be managed. The data will remain unchanged, but the original python values will be restored if you update the packages. >>>> >>>> I?m ok with that because the values only need to be set during initial setup. Any idea why the validator isn?t being modified? >>>>> >>>>> I don't believe validators are currently extensible in the IPA framework. That might be something we need to look at as well. >>>>> >>>>> regards >>>>> >>>>> rob >>>>> >>>> >>>> Thanks for the help. >>> >>> Sure. I'm glad we made at least obvious enough for you to be able to work around. >>> >>> So I'm just curious about the need for this. You mentioned that semanage slows way down. Have you talked to the SELinux team about this? They've been quite responsive to our needs in the past, they may be able to fix something for you as well. >> >> I?m not sure if my coworker has talked to them about it directly, no. I?ll ping him to see if it?s something we want to get worked on moving forward. >>> >>> On a more general note, we haven't had a lot of user feedback on the SELinux user map feature. Do you have any other suggestions on things we might do to improve it? >> >> Nothing directly but I can describe how we?re using it and where some of the perceived pain points are. Their impact is negligible though so we haven?t felt the need to investigate better ways to work around them. >> >> We?ve got a network of systems running both targeted and MLS SELinux policy. What this means is that we must define both valid selinux context is the user map. I.e. we define both staff_u:s0-s0:c0.c1023 and staff_u:s0-s15:c0.c1023 in the user map. We then use host groups and multiple user maps to map appropriately. Our commands might be easier to understand: >> >> ipa config-mod --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$staff_u:s0-s15:c0.c1023? >> ipa hostgroup-add mls --desc="MLS SELinux Group? >> ipa hostgroup-add-member mls --hosts=mlshost1,mlshost2 >> ipa hostgroup-add targeted --desc="Targeted SELinux Group? >> ipa hostgroup-add-member targeted --hosts=appsrv1,appsrv2 >> ipa selinuxusermap-add staff_u --selinuxuser=staff_u:s0-s0:c0.c1023 >> ipa selinuxusermap-add staff_u_MLS --selinuxuser=staff_u:s0-s15:c0.c1023 >> ipa selinuxusermap-add-host staff_u --hostgroups=targeted >> ipa selinuxusermap-add-host staff_u_MLS --hostgroups=mls >> ipa selinuxusermap-add-user staff_u --groups=wheel >> ipa selinuxusermap-add-user staff_u_MLS --groups=wheel >> >> It might be more straightforward if we didn?t have to split the configuration like this but thanks to the flexibility of FreeIPA it?s very easy to do. >> >> Thanks, >> -josh > > Nice. Not many of our users got back to us with experience on using the > advanced use of the SELinux feature - so feedback welcome! > > Rob, I am wondering if it would make sense to extend the FreeIPA to allow > SELinux user map rules with more SELinux users, per policy? I.e. have a rule > like that: > > # ipa selinuxusermap-show staff_u > Rule name: staff_u > SELinux User: staff_u:s0-s0:c0.c1023 > SELinux User (mls): staff_u:s0-s15:c0.c1023 > Enabled: TRUE > User Groups: wheel > Host Groups: selinuxhosts > > > This proposed rule structure is not ideal and would require updated IPA&SSSD on > all machines but it should explain the idea. > > Martin > I think this would be handy if one had a lot of SELinux user categories but I don't think that is typical. Then again, I hadn't considered the case of different MLS levels either, so take it with a grain of salt. rob From bclark at tendrilinc.com Thu Feb 13 15:15:52 2014 From: bclark at tendrilinc.com (Brent Clark) Date: Thu, 13 Feb 2014 08:15:52 -0700 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line Message-ID: I have run into a problem where I cannot delete PTR DNS records from the command line. This is something that until recently I have never attempted. IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 When I try to delete a PTR record I get this message. ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com ipa: ERROR: 250: DNS resource record not found ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified Its got to be a simple thing I am missing, can someone please show what I am doing wrong? Thanks! -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 13 15:23:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Feb 2014 16:23:21 +0100 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line In-Reply-To: References: Message-ID: <52FCE369.3000306@redhat.com> On 02/13/2014 04:15 PM, Brent Clark wrote: > I have run into a problem where I cannot delete PTR DNS records from the > command line. This is something that until recently I have never attempted. > > IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 > > When I try to delete a PTR record I get this message. > ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 > ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified > > ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com > ipa: ERROR: 250: DNS resource record not found > > ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 > ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified > > Its got to be a simple thing I am missing, can someone please show what I > am doing wrong? > > Thanks! Unqualified PTR records do not make sense, this is why we validate them on addition. What does following command show? $ ipa dnsrecord-show 41.100.10.in-addr-arpa. 250 Is the record really resolvable? $ host 10.100.41.250 Martin From pspacek at redhat.com Thu Feb 13 15:23:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Feb 2014 16:23:23 +0100 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line In-Reply-To: References: Message-ID: <52FCE36B.7050606@redhat.com> On 13.2.2014 16:15, Brent Clark wrote: > I have run into a problem where I cannot delete PTR DNS records from the > command line. This is something that until recently I have never attempted. > > IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 > > When I try to delete a PTR record I get this message. > ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 > ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified > > ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com > ipa: ERROR: 250: DNS resource record not found > > ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 > ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified > > Its got to be a simple thing I am missing, can someone please show what I > am doing wrong? Please send us output from commands: $ ipa dnszone-show 41.100.10.in-addr-arpa. $ ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 Thank you. -- Petr^2 Spacek From bclark at tendrilinc.com Thu Feb 13 15:40:24 2014 From: bclark at tendrilinc.com (Brent Clark) Date: Thu, 13 Feb 2014 08:40:24 -0700 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line In-Reply-To: <52FCE36B.7050606@redhat.com> References: <52FCE36B.7050606@redhat.com> Message-ID: Here are the results of the commands asked for. Also attached is a png of the webui showing the zone and record exists that I want to delete. Many Thanks! ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 ---------------------------- Number of entries returned 0 ---------------------------- ipa dnszone-show 41.100.10.in-addr-arpa. ipa: ERROR: 41.100.10.in-addr-arpa.: DNS zone not found host 10.100.41.250 250.41.100.10.in-addr.arpa domain name pointer test1.test.com. On Thu, Feb 13, 2014 at 8:23 AM, Petr Spacek wrote: > On 13.2.2014 16:15, Brent Clark wrote: > >> I have run into a problem where I cannot delete PTR DNS records from the >> command line. This is something that until recently I have never >> attempted. >> >> IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 >> >> When I try to delete a PTR record I get this message. >> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 >> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >> >> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com >> ipa: ERROR: 250: DNS resource record not found >> >> ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 >> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >> >> Its got to be a simple thing I am missing, can someone please show what I >> am doing wrong? >> > > Please send us output from commands: > > $ ipa dnszone-show 41.100.10.in-addr-arpa. > $ ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 > > Thank you. > > -- > Petr^2 Spacek > -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 41.100.10-reversednszone.png Type: image/png Size: 19453 bytes Desc: not available URL: From pvoborni at redhat.com Thu Feb 13 16:25:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Feb 2014 17:25:19 +0100 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line In-Reply-To: References: <52FCE36B.7050606@redhat.com> Message-ID: <52FCF1EF.4080004@redhat.com> Hello, The zone name is: 41.100.10.in-addr.arpa. Not: 41.100.10.in-addr-arpa. HTH On 13.2.2014 16:40, Brent Clark wrote: > Here are the results of the commands asked for. Also attached is a png of > the webui showing the zone and record exists that I want to delete. > > Many Thanks! > > > ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 > ---------------------------- > Number of entries returned 0 > ---------------------------- > > ipa dnszone-show 41.100.10.in-addr-arpa. > ipa: ERROR: 41.100.10.in-addr-arpa.: DNS zone not found > > host 10.100.41.250 > 250.41.100.10.in-addr.arpa domain name pointer test1.test.com. > > > > > On Thu, Feb 13, 2014 at 8:23 AM, Petr Spacek wrote: > >> On 13.2.2014 16:15, Brent Clark wrote: >> >>> I have run into a problem where I cannot delete PTR DNS records from the >>> command line. This is something that until recently I have never >>> attempted. >>> >>> IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 >>> >>> When I try to delete a PTR record I get this message. >>> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 >>> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >>> >>> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com >>> ipa: ERROR: 250: DNS resource record not found >>> >>> ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 >>> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >>> >>> Its got to be a simple thing I am missing, can someone please show what I >>> am doing wrong? >>> >> >> Please send us output from commands: >> >> $ ipa dnszone-show 41.100.10.in-addr-arpa. >> $ ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 >> >> Thank you. >> >> -- >> Petr^2 Spacek >> > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Petr Vobornik From bruno-barbosa at prodesan.com.br Thu Feb 13 17:55:13 2014 From: bruno-barbosa at prodesan.com.br (Bruno Henrique Barbosa) Date: Thu, 13 Feb 2014 15:55:13 -0200 (BRST) Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: Message-ID: <87eeeb84-5804-4e63-9a62-9bdd5a27dce5@prod190.prodesan.com.br> Hi everyone, I've installed my IPA environment as it follows: ipa01.example.com - master install ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: IPA Error 4203 Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Via command-line, debug-enabled: root at ipa02's password: Last login: Thu Feb 13 15:36:34 2014 [root at ipa02 ~]# kinit admin Password for admin at EXAMPLE.COM: [root at ipa02 ~]# ipa-replica-manage list ipa01.example.com: master ipa02.example.com: master [root at ipa02 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at EXAMPLE.COM Valid starting Expires Service principal 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM [root at ipa02 ~]# ipa -d user-add usertest ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: args=klist -V ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' ipa: INFO: trying https://ipa02.example.com/ipa/xml ipa: DEBUG: NSSConnection init ipa02.example.com ipa: DEBUG: Connecting: 192.168.0.2:0 ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 14 (0xe) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=EXAMPLE.COM Validity: Not Before: Qua Fev 12 19:42:11 2014 UTC Not After: S?b Fev 13 19:42:11 2016 UTC Subject: CN=ipa02.example.com,O=EXAMPLE.COM Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd Exponent: 65537 (0x10001) Signed Extensions: (5) Name: Certificate Authority Key Identifier Critical: False Key ID: 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: c3:9c:48:63 Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Subject Key ID Critical: False Data: ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: 55:7c:07:ec Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 Fingerprint (MD5): 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf Fingerprint (SHA1): a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: 66:6e:f7:77 ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s ipa: DEBUG: stdout=227287872 ipa: DEBUG: stderr= ipa: DEBUG: Created connection context.xmlclient First name: usertest Last name: testname ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' ipa: DEBUG: NSSConnection init ipa02.example.com ipa: DEBUG: Connecting: 192.168.0.2:0 ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM ipa: DEBUG: stdout=227287872 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM ipa: DEBUG: stdout=227287872 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl pupdate 227287872 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! Thank you for any help you can provide in this situation! Bruno Henrique Barbosa Jr. Sys Admin IT Department Santos City Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From bclark at tendrilinc.com Thu Feb 13 18:25:51 2014 From: bclark at tendrilinc.com (Brent Clark) Date: Thu, 13 Feb 2014 11:25:51 -0700 Subject: [Freeipa-users] cannot delete PTR DNS records from the command line In-Reply-To: <52FCF1EF.4080004@redhat.com> References: <52FCE36B.7050606@redhat.com> <52FCF1EF.4080004@redhat.com> Message-ID: Hmm, amazing what works when you spell stuff right. Epic Fail on my part. Face plant in the mud. Apologies to all for such silliness that I have put you all thru. Thanks! On Thu, Feb 13, 2014 at 9:25 AM, Petr Vobornik wrote: > Hello, > > The zone name is: > 41.100.10.in-addr.arpa. > Not: > 41.100.10.in-addr-arpa. > > HTH > > > On 13.2.2014 16:40, Brent Clark wrote: > >> Here are the results of the commands asked for. Also attached is a png of >> the webui showing the zone and record exists that I want to delete. >> >> Many Thanks! >> >> >> ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- >> >> ipa dnszone-show 41.100.10.in-addr-arpa. >> ipa: ERROR: 41.100.10.in-addr-arpa.: DNS zone not found >> >> host 10.100.41.250 >> 250.41.100.10.in-addr.arpa domain name pointer test1.test.com. >> >> >> >> >> On Thu, Feb 13, 2014 at 8:23 AM, Petr Spacek wrote: >> >> On 13.2.2014 16:15, Brent Clark wrote: >>> >>> I have run into a problem where I cannot delete PTR DNS records from the >>>> command line. This is something that until recently I have never >>>> attempted. >>>> >>>> IPA version = ipa-server-2.2.0-17.el6_3.1.x86_64 >>>> >>>> When I try to delete a PTR record I get this message. >>>> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1 >>>> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >>>> >>>> ipa dnsrecord-del 41.100.10.in-addr-arpa. 250 --ptr-rec test1.test.com >>>> ipa: ERROR: 250: DNS resource record not found >>>> >>>> ipa dnsrecord-del 41.100.10.in-addr-arpa. test1.test.com. --ptr-rec 250 >>>> ipa: ERROR: invalid 'hostname': invalid domain-name: not fully qualified >>>> >>>> Its got to be a simple thing I am missing, can someone please show what >>>> I >>>> am doing wrong? >>>> >>>> >>> Please send us output from commands: >>> >>> $ ipa dnszone-show 41.100.10.in-addr-arpa. >>> $ ipa dnsrecord-find 41.100.10.in-addr-arpa. 250 >>> >>> Thank you. >>> >>> -- >>> Petr^2 Spacek >>> >>> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -- > Petr Vobornik > -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 13 18:30:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 13:30:22 -0500 Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: <87eeeb84-5804-4e63-9a62-9bdd5a27dce5@prod190.prodesan.com.br> References: <87eeeb84-5804-4e63-9a62-9bdd5a27dce5@prod190.prodesan.com.br> Message-ID: <52FD0F3E.6090509@redhat.com> On 02/13/2014 12:55 PM, Bruno Henrique Barbosa wrote: > Hi everyone, > > I've installed my IPA environment as it follows: > > ipa01.example.com - master install > ipa02.example.com - replica install, as the guide says, with > ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key > generated. > > All good, environment is fine, can access both UI, but the underlying > problem is: I can edit and remove users from IPA using instance ipa02 > (replica), but I CANNOT add users from that instance. In the UI, error > returned is: > > IPA Error 4203 > Operations error: Allocation of a new value for range cn=posix > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config > failed! Unable to proceed. > > > Via command-line, debug-enabled: > > root at ipa02's password: > Last login: Thu Feb 13 15:36:34 2014 > [root at ipa02 ~]# kinit admin > Password for admin at EXAMPLE.COM: > [root at ipa02 ~]# ipa-replica-manage list > ipa01.example.com: master > ipa02.example.com: master > [root at ipa02 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > > Valid starting Expires Service principal > 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM > 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM > [root at ipa02 ~]# ipa -d user-add usertest > ipa: DEBUG: importing all plugin modules in > '/usr/lib/python2.6/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: args=klist -V > ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > ipa: DEBUG: failed to find session_cookie in persistent storage for > principal 'admin at EXAMPLE.COM' > ipa: INFO: trying https://ipa02.example.com/ipa/xml > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 14 (0xe) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=EXAMPLE.COM > Validity: > Not Before: Qua Fev 12 19:42:11 2014 UTC > Not After: S?b Fev 13 19:42:11 2016 UTC > Subject: CN=ipa02.example.com,O=EXAMPLE.COM > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: > f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: > 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: > 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: > 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: > e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: > 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: > 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: > 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: > db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: > 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: > 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: > c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: > d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: > 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: > c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd > Exponent: > 65537 (0x10001) > Signed Extensions: (5) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: > c3:9c:48:63 > Serial Number: None > General Names: [0 total] > > Name: Authority Information Access > Critical: False > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > Name: Certificate Subject Key ID > Critical: False > Data: > ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: > 55:7c:07:ec > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: > 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: > f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: > 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: > 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: > 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: > f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: > 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: > 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: > df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: > f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: > 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: > 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: > bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: > c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: > 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 > Fingerprint (MD5): > 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf > Fingerprint (SHA1): > a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: > 66:6e:f7:77 > ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie > 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; > Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 > GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie > 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; > Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 > GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s > ipa: DEBUG: stdout=227287872 > > ipa: DEBUG: stderr= > ipa: DEBUG: Created connection context.xmlclient > First name: usertest > Last name: testname > ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', > sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, > noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) > ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', > sn=u'testname', cn=u'usertest testname', displayname=u'usertest > testname', initials=u'ut', gecos=u'usertest testname', > krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, > gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', > no_members=False) > ipa: INFO: Forwarding 'user_add' to server > u'https://ipa02.example.com/ipa/xml' > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie > 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; > Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 > GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie > 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; > Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 > GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl search @s user > ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl pupdate 227287872 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Caught fault 4203 from server > https://ipa02.example.com/ipa/xml: Operations error: Allocation of a > new value for range cn=posix ids,cn=distributed numeric assignment > plugin,cn=plugins,cn=config failed! Unable to proceed. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Operations error: Allocation of a new value for range > cn=posix ids,cn=distributed numeric assignment > plugin,cn=plugins,cn=config failed! Unable to proceed. > > > Under the labs I did on IPA, I could resolve that by booting the > replica server, but this time I couldn't solve. Looking for > assistance, please! Looks like problems with the DNA plugin. Did you by any chance tried to install and untinstall replica for couple dozen times? I think we would need replica DS logs and the DNA plugin configuration entries from primary and replica servers. > > Thank you for any help you can provide in this situation! > > Bruno Henrique Barbosa > Jr. Sys Admin > IT Department > Santos City Hall > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bclark at tendrilinc.com Thu Feb 13 18:51:27 2014 From: bclark at tendrilinc.com (Brent Clark) Date: Thu, 13 Feb 2014 11:51:27 -0700 Subject: [Freeipa-users] WebUI questions. Message-ID: When I assign a user the role of "User Administrator", when they log into the WebUI, they can see all the role, dns, config, tab and links. They should only see the necessary tabs and links that having that role requires and none of the extra stuff. Is there a way to limit when appears in the WebUI based on Role? -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.moyer at digitalreasoning.com Thu Feb 13 18:56:05 2014 From: john.moyer at digitalreasoning.com (John Moyer) Date: Thu, 13 Feb 2014 13:56:05 -0500 Subject: [Freeipa-users] IPA not Starting after crash Message-ID: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> Hello All, We?ve been running IPA now nicely for a while, and I wrote a script to run something every minute and that filled the logs and crashed the server. I cleared the logs and started IPA again. [root@ log]# ipactl start Starting Directory Service Starting dirsrv: DIGITALREASONING-COM... already running [ OK ] PKI-IPA... already running [ OK ] Failed to read data from Directory Service: Failed to get list of services to probe status! Configured hostname ?blah.digitalreasoning.com' does not match any master server in LDAP: No master found because of error: {'matched': 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} Thanks, _____________________________________________________ John Moyer Director, IT Operations -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcritten at redhat.com Thu Feb 13 19:09:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 14:09:05 -0500 Subject: [Freeipa-users] WebUI questions. In-Reply-To: References: Message-ID: <52FD1851.40705@redhat.com> Brent Clark wrote: > When I assign a user the role of "User Administrator", when they log > into the WebUI, they can see all the role, dns, config, tab and links. > > They should only see the necessary tabs and links that having that role > requires and none of the extra stuff. > > Is there a way to limit when appears in the WebUI based on Role? Not yet, see https://fedorahosted.org/freeipa/ticket/217 rob From rcritten at redhat.com Thu Feb 13 19:10:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Feb 2014 14:10:40 -0500 Subject: [Freeipa-users] IPA not Starting after crash In-Reply-To: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> References: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> Message-ID: <52FD18B0.4050404@redhat.com> John Moyer wrote: > Hello All, > > We?ve been running IPA now nicely for a while, and I wrote a script to > run something every minute and that filled the logs and crashed the > server. I cleared the logs and started IPA again. > > > [root@ log]# ipactl start > Starting Directory Service > Starting dirsrv: > DIGITALREASONING-COM... already running [ OK ] > PKI-IPA... already running [ OK ] > Failed to read data from Directory Service: Failed to get list of > services to probe status! > Configured hostname ?blah.digitalreasoning.com > ' does not match any master server in > LDAP: > No master found because of error: {'matched': > 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} I'd check /var/log/dirsrv/slapd-DIGITALREASONNG-COM/errors to see if there are any database consistency problems. rob From john.moyer at digitalreasoning.com Thu Feb 13 19:12:26 2014 From: john.moyer at digitalreasoning.com (John Moyer) Date: Thu, 13 Feb 2014 14:12:26 -0500 Subject: [Freeipa-users] IPA not Starting after crash In-Reply-To: <52FD18B0.4050404@redhat.com> References: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> <52FD18B0.4050404@redhat.com> Message-ID: This is the error log when I try to start it: [13/Feb/2014:19:08:28 +0000] - 389-Directory/1.2.11.15 B2013.357.177 starting up [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=digitalreasoning,dc=com [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=groups, cn=compat,dc=digitalreasoning,dc=com [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=digitalreasoning,dc=com [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=digitalreasoning,dc=com [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=users, cn=compat,dc=digitalreasoning,dc=com [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: Unable to locate shared configuration entry (cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=digitalreasoning,dc=com) [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: Invalid config entry [cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped [13/Feb/2014:19:08:28 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [13/Feb/2014:19:08:28 +0000] - Listening on All Interfaces port 636 for LDAPS requests [13/Feb/2014:19:08:28 +0000] - Listening on /var/run/slapd-DIGITALREASONING-COM.socket for LDAPI requests [13/Feb/2014:19:08:30 +0000] - slapd shutting down - signaling operation threads [13/Feb/2014:19:08:30 +0000] - slapd shutting down - closing down internal subsystems and plugins [13/Feb/2014:19:08:30 +0000] - Waiting for 4 database threads to stop [13/Feb/2014:19:08:30 +0000] - All database threads now stopped [13/Feb/2014:19:08:30 +0000] - slapd stopped. Thanks, _____________________________________________________ John Moyer Director, IT Operations On Feb 13, 2014, at 2:10 PM, Rob Crittenden wrote: > John Moyer wrote: >> Hello All, >> >> We?ve been running IPA now nicely for a while, and I wrote a script to >> run something every minute and that filled the logs and crashed the >> server. I cleared the logs and started IPA again. >> >> >> [root@ log]# ipactl start >> Starting Directory Service >> Starting dirsrv: >> DIGITALREASONING-COM... already running [ OK ] >> PKI-IPA... already running [ OK ] >> Failed to read data from Directory Service: Failed to get list of >> services to probe status! >> Configured hostname ?blah.digitalreasoning.com >> ' does not match any master server in >> LDAP: >> No master found because of error: {'matched': >> 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} > > I'd check /var/log/dirsrv/slapd-DIGITALREASONNG-COM/errors to see if there are any database consistency problems. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dpal at redhat.com Thu Feb 13 19:17:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 14:17:21 -0500 Subject: [Freeipa-users] WebUI questions. In-Reply-To: References: Message-ID: <52FD1A41.90905@redhat.com> On 02/13/2014 01:51 PM, Brent Clark wrote: > When I assign a user the role of "User Administrator", when they log > into the WebUI, they can see all the role, dns, config, tab and links. > > They should only see the necessary tabs and links that having that > role requires and none of the extra stuff. > > Is there a way to limit when appears in the WebUI based on Role? https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#server-access-controls > > -- > Brent S. Clark > NOC Engineer > > 2580 55th St. | Boulder, Colorado 80301 > www.tendrilinc.com | blog > > > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. > Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. > Finally, the recipient should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus transmitted by this email. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 13 19:20:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 14:20:41 -0500 Subject: [Freeipa-users] IPA not Starting after crash In-Reply-To: References: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> <52FD18B0.4050404@redhat.com> Message-ID: <52FD1B09.6040207@redhat.com> On 02/13/2014 02:12 PM, John Moyer wrote: > This is the error log when I try to start it: > > [13/Feb/2014:19:08:28 +0000] - 389-Directory/1.2.11.15 B2013.357.177 > starting up > [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=digitalreasoning,dc=com > [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no > entries set up under cn=groups, cn=compat,dc=digitalreasoning,dc=com > [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=digitalreasoning,dc=com > [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=digitalreasoning,dc=com > [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no > entries set up under cn=users, cn=compat,dc=digitalreasoning,dc=com > [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: > Unable to locate shared configuration entry > (cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=digitalreasoning,dc=com) > [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: > Invalid config entry [cn=posix ids,cn=distributed numeric assignment > plugin,cn=plugins,cn=config] skipped > [13/Feb/2014:19:08:28 +0000] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [13/Feb/2014:19:08:28 +0000] - Listening on All Interfaces port 636 > for LDAPS requests > [13/Feb/2014:19:08:28 +0000] - Listening on > /var/run/slapd-DIGITALREASONING-COM.socket for LDAPI requests > [13/Feb/2014:19:08:30 +0000] - slapd shutting down - signaling > operation threads > [13/Feb/2014:19:08:30 +0000] - slapd shutting down - closing down > internal subsystems and plugins > [13/Feb/2014:19:08:30 +0000] - Waiting for 4 database threads to stop > [13/Feb/2014:19:08:30 +0000] - All database threads now stopped > [13/Feb/2014:19:08:30 +0000] - slapd stopped. Seems like your dna-plugin configuration is corrupted or missing. The easiest way would be probably to reinit or reinstall replica. If we want to try to repair we need help from DS team. > > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > > On Feb 13, 2014, at 2:10 PM, Rob Crittenden > wrote: > >> John Moyer wrote: >>> Hello All, >>> >>> We've been running IPA now nicely for a while, and I wrote a script to >>> run something every minute and that filled the logs and crashed the >>> server. I cleared the logs and started IPA again. >>> >>> >>> [root@ log]# ipactl start >>> Starting Directory Service >>> Starting dirsrv: >>> DIGITALREASONING-COM... already running [ OK ] >>> PKI-IPA... already running [ OK ] >>> Failed to read data from Directory Service: Failed to get list of >>> services to probe status! >>> Configured hostname 'blah.digitalreasoning.com >>> >>> ' does not match any master server in >>> LDAP: >>> No master found because of error: {'matched': >>> 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} >> >> I'd check /var/log/dirsrv/slapd-DIGITALREASONNG-COM/errors to see if >> there are any database consistency problems. >> >> rob >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.moyer at digitalreasoning.com Thu Feb 13 19:58:05 2014 From: john.moyer at digitalreasoning.com (John Moyer) Date: Thu, 13 Feb 2014 14:58:05 -0500 Subject: [Freeipa-users] IPA not Starting after crash In-Reply-To: <52FD1B09.6040207@redhat.com> References: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> <52FD18B0.4050404@redhat.com> <52FD1B09.6040207@redhat.com> Message-ID: <5F38A81E-C9D0-4E86-BF64-CD410C2DF243@digitalreasoning.com> I think I know my problem, back in August I was having performance issues so I hooked part of my IPA server to RAM disk. I?m assuming looking at the symlink below that since I?ve rebooted the server that I?m completely out of luck. This is in this directory : /var/lib/dirsrv/slapd-DIGITALREASONING-COM/ lrwxrwxrwx 1 root root 12 Aug 27 03:21 db -> /dev/shm/db/ At this point I just want confirmation that my data is gone. I was doing backups, but of the disks not the RAM. Thanks, _____________________________________________________ John Moyer Director, IT Operations On Feb 13, 2014, at 2:20 PM, Dmitri Pal wrote: > On 02/13/2014 02:12 PM, John Moyer wrote: >> >> This is the error log when I try to start it: >> >> [13/Feb/2014:19:08:28 +0000] - 389-Directory/1.2.11.15 B2013.357.177 starting up >> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=digitalreasoning,dc=com >> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=groups, cn=compat,dc=digitalreasoning,dc=com >> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=digitalreasoning,dc=com >> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=digitalreasoning,dc=com >> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no entries set up under cn=users, cn=compat,dc=digitalreasoning,dc=com >> [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: Unable to locate shared configuration entry (cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=digitalreasoning,dc=com) >> [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: Invalid config entry [cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped >> [13/Feb/2014:19:08:28 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests >> [13/Feb/2014:19:08:28 +0000] - Listening on All Interfaces port 636 for LDAPS requests >> [13/Feb/2014:19:08:28 +0000] - Listening on /var/run/slapd-DIGITALREASONING-COM.socket for LDAPI requests >> [13/Feb/2014:19:08:30 +0000] - slapd shutting down - signaling operation threads >> [13/Feb/2014:19:08:30 +0000] - slapd shutting down - closing down internal subsystems and plugins >> [13/Feb/2014:19:08:30 +0000] - Waiting for 4 database threads to stop >> [13/Feb/2014:19:08:30 +0000] - All database threads now stopped >> [13/Feb/2014:19:08:30 +0000] - slapd stopped. > > Seems like your dna-plugin configuration is corrupted or missing. > The easiest way would be probably to reinit or reinstall replica. > If we want to try to repair we need help from DS team. > > >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> Director, IT Operations >> >> On Feb 13, 2014, at 2:10 PM, Rob Crittenden wrote: >> >>> John Moyer wrote: >>>> Hello All, >>>> >>>> We?ve been running IPA now nicely for a while, and I wrote a script to >>>> run something every minute and that filled the logs and crashed the >>>> server. I cleared the logs and started IPA again. >>>> >>>> >>>> [root@ log]# ipactl start >>>> Starting Directory Service >>>> Starting dirsrv: >>>> DIGITALREASONING-COM... already running [ OK ] >>>> PKI-IPA... already running [ OK ] >>>> Failed to read data from Directory Service: Failed to get list of >>>> services to probe status! >>>> Configured hostname ?blah.digitalreasoning.com >>>> ' does not match any master server in >>>> LDAP: >>>> No master found because of error: {'matched': >>>> 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} >>> >>> I'd check /var/log/dirsrv/slapd-DIGITALREASONNG-COM/errors to see if there are any database consistency problems. >>> >>> rob >>> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sdainard at miovision.com Thu Feb 13 20:05:07 2014 From: sdainard at miovision.com (Steve Dainard) Date: Thu, 13 Feb 2014 15:05:07 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140213084637.GF1342@hendrix.redhat.com> References: <20140212120745.GM8040@redhat.com> <52FB6675.5010503@martos.bme.hu> <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> Message-ID: Is this server or client side where sudo_provider=ipa is included in ver > 1.11.x? My fedora 20 client doesn't have this option listed, or is it baked in? *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Thu, Feb 13, 2014 at 3:46 AM, Jakub Hrozek wrote: > On Wed, Feb 12, 2014 at 03:35:58PM -0800, Will Sheldon wrote: > > Is SSSD working for IPA sudo now? > > It was working even before, just with a bit of manual config, as I said > in the reply you quoted, you just had to configure 'sudo_provider=ldap' > > > I saw this From Jakub Horozek in this list a little while back: > > > > Unfortunately with 6.5 there is still no sudo ipa provider, there might > > be with one in 6.6. So in order to download the sudo rules you need to > > configure the LDAP sudo provider manually. > > sudo_provider=ipa is included in 1.9.6 and also all recent versions > (1.11.x) > > We're thinking about including a newer version in RHEL-6.6, where the > sudo_provider=ipa would be included as well. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Feb 13 20:53:58 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Feb 2014 13:53:58 -0700 Subject: [Freeipa-users] IPA not Starting after crash In-Reply-To: <5F38A81E-C9D0-4E86-BF64-CD410C2DF243@digitalreasoning.com> References: <1EA12F9D-D8D1-4E46-8A04-B2339D16DBD1@digitalreasoning.com> <52FD18B0.4050404@redhat.com> <52FD1B09.6040207@redhat.com> <5F38A81E-C9D0-4E86-BF64-CD410C2DF243@digitalreasoning.com> Message-ID: <52FD30E6.2070302@redhat.com> On 02/13/2014 12:58 PM, John Moyer wrote: > I think I know my problem, back in August I was having performance > issues so I hooked part of my IPA server to RAM disk. I'm assuming > looking at the symlink below that since I've rebooted the server that > I'm completely out of luck. > > This is in this directory : /var/lib/dirsrv/slapd-DIGITALREASONING-COM/ > > lrwxrwxrwx 1 root root 12 Aug 27 03:21 db -> /dev/shm/db/ > > At this point I just want confirmation that my data is gone. I was > doing backups, but of the disks not the RAM. I'm not sure where else the data would be, if it is not in /dev/shm/db, and not in /var/lib/dirsrv/slapd-DOMAIN Do you have a replica? > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > > On Feb 13, 2014, at 2:20 PM, Dmitri Pal > wrote: > >> On 02/13/2014 02:12 PM, John Moyer wrote: >>> This is the error log when I try to start it: >>> >>> [13/Feb/2014:19:08:28 +0000] - 389-Directory/1.2.11.15 B2013.357.177 >>> starting up >>> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no >>> entries set up under cn=computers, cn=compat,dc=digitalreasoning,dc=com >>> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no >>> entries set up under cn=groups, cn=compat,dc=digitalreasoning,dc=com >>> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no >>> entries set up under cn=ng, cn=compat,dc=digitalreasoning,dc=com >>> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no >>> entries set up under ou=sudoers,dc=digitalreasoning,dc=com >>> [13/Feb/2014:19:08:28 +0000] schema-compat-plugin - warning: no >>> entries set up under cn=users, cn=compat,dc=digitalreasoning,dc=com >>> [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: >>> Unable to locate shared configuration entry >>> (cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=digitalreasoning,dc=com) >>> [13/Feb/2014:19:08:28 +0000] dna-plugin - dna_parse_config_entry: >>> Invalid config entry [cn=posix ids,cn=distributed numeric assignment >>> plugin,cn=plugins,cn=config] skipped >>> [13/Feb/2014:19:08:28 +0000] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> [13/Feb/2014:19:08:28 +0000] - Listening on All Interfaces port 636 >>> for LDAPS requests >>> [13/Feb/2014:19:08:28 +0000] - Listening on >>> /var/run/slapd-DIGITALREASONING-COM.socket for LDAPI requests >>> [13/Feb/2014:19:08:30 +0000] - slapd shutting down - signaling >>> operation threads >>> [13/Feb/2014:19:08:30 +0000] - slapd shutting down - closing down >>> internal subsystems and plugins >>> [13/Feb/2014:19:08:30 +0000] - Waiting for 4 database threads to stop >>> [13/Feb/2014:19:08:30 +0000] - All database threads now stopped >>> [13/Feb/2014:19:08:30 +0000] - slapd stopped. >> >> Seems like your dna-plugin configuration is corrupted or missing. >> The easiest way would be probably to reinit or reinstall replica. >> If we want to try to repair we need help from DS team. >> >> >>> >>> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> Director, IT Operations >>> >>> On Feb 13, 2014, at 2:10 PM, Rob Crittenden >> > wrote: >>> >>>> John Moyer wrote: >>>>> Hello All, >>>>> >>>>> We've been running IPA now nicely for a while, and I wrote a script to >>>>> run something every minute and that filled the logs and crashed the >>>>> server. I cleared the logs and started IPA again. >>>>> >>>>> >>>>> [root@ log]# ipactl start >>>>> Starting Directory Service >>>>> Starting dirsrv: >>>>> DIGITALREASONING-COM... already running [ OK ] >>>>> PKI-IPA... already running [ OK ] >>>>> Failed to read data from Directory Service: Failed to get list of >>>>> services to probe status! >>>>> Configured hostname 'blah.digitalreasoning.com >>>>> >>>>> >>>> >' does not match any master >>>>> server in >>>>> LDAP: >>>>> No master found because of error: {'matched': >>>>> 'dc=digitalreasoning,dc=com', 'desc': 'No such object'} >>>> >>>> I'd check /var/log/dirsrv/slapd-DIGITALREASONNG-COM/errors to see >>>> if there are any database consistency problems. >>>> >>>> rob >>>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Feb 13 22:15:43 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 13 Feb 2014 23:15:43 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: References: <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> Message-ID: <20140213221543.GZ1342@hendrix.redhat.com> On Thu, Feb 13, 2014 at 03:05:07PM -0500, Steve Dainard wrote: > Is this server or client side where sudo_provider=ipa is included in ver > > 1.11.x? Client side (sssd) > > My fedora 20 client doesn't have this option listed, or is it baked in? > Where exactly do you see the documentation lacking, perhaps the sssd-ipa man page, or the sssd-sudo man page? I agree that docs are important, but my view might be skewed because I know the internals.. All that should be required with 1.9.6 or 1.11.x is: sudo_provider=ipa And enabling the 'sss' module in /etc/nsswitch.conf: sudoers: files sss That's it. Please let us know if you find any bugs in code or docs. From sdainard at miovision.com Thu Feb 13 23:04:44 2014 From: sdainard at miovision.com (Steve Dainard) Date: Thu, 13 Feb 2014 18:04:44 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140213221543.GZ1342@hendrix.redhat.com> References: <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> <20140213221543.GZ1342@hendrix.redhat.com> Message-ID: I don't think this is an issue of bugs or documentation, more of design. Perhaps there's someplace other than a users list this belongs in but: If IPA is a centrally managed identity and access control system, should these configurations not be passed to clients, rather than every client needing configuration changes post join? Obviously I can automate config changes, but why would I want to? I don't think sudoers priv is a fringe case, its pretty much THE case for access/admin control. I cringe to compare to a Windows domain, but I don't have to manually tell a domain client that it should respect the rules I set on a domain controller, I joined it to the domain for this reason. Maybe you're working towards this, but in the meantime it would be great if the options existed in the config files so we immediately know what options are available and can comment/uncomment them rather than searching around man pages for options that might exist. I believe you were looking for a documentation bug: # man sssd-sudo To enable SSSD as a source for sudo rules, *add sss to the sudoers entry* in nsswitch.conf(5). For example, to configure sudo to first lookup rules in the standard sudoers(5) file (which should contain rules that apply to local users) and then in SSSD, the nsswitch.conf file should contain the following line: * sudoers: files sss* # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #initgroups: files #hosts: db files nisplus nis dns hosts: files mdns4_minimal [NOTFOUND=return] 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 Entry does not exist. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Thu, Feb 13, 2014 at 5:15 PM, Jakub Hrozek wrote: > On Thu, Feb 13, 2014 at 03:05:07PM -0500, Steve Dainard wrote: > > Is this server or client side where sudo_provider=ipa is included in ver > > > > 1.11.x? > > Client side (sssd) > > > > > My fedora 20 client doesn't have this option listed, or is it baked in? > > > > Where exactly do you see the documentation lacking, perhaps the sssd-ipa > man page, or the sssd-sudo man page? I agree that docs are important, > but my view might be skewed because I know the internals.. > > All that should be required with 1.9.6 or 1.11.x is: > sudo_provider=ipa > > And enabling the 'sss' module in /etc/nsswitch.conf: > sudoers: files sss > > That's it. Please let us know if you find any bugs in code or docs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Thu Feb 13 23:17:43 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Thu, 13 Feb 2014 23:17:43 +0000 Subject: [Freeipa-users] Setting up sudo Message-ID: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> the documentation is kinda vague on some parts from the documentation: Because the sudo information is not available anonymously over LDAP by default, Identity Management defines a default sudo user, uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo configuration file, /etc/sud-ldap.conf. so is this user supposed to already pre defined. or do I need to create the user, and then modify them thanks -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Thu Feb 13 23:23:01 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Thu, 13 Feb 2014 23:23:01 +0000 Subject: [Freeipa-users] Setting up sudo In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> Message-ID: <6FB698E172A95F49BE009B36D56F53E2273242@EXCHMB1-ELS.BWINC.local> and If I am configuring the sud-ldap.conf what should it look like does any one have an example? ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com] Sent: Thursday, February 13, 2014 3:17 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] Setting up sudo the documentation is kinda vague on some parts from the documentation: Because the sudo information is not available anonymously over LDAP by default, Identity Management defines a default sudo user, uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo configuration file, /etc/sud-ldap.conf. so is this user supposed to already pre defined. or do I need to create the user, and then modify them thanks -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 13 23:23:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 18:23:51 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: References: <20140212123406.GN8040@redhat.com> <52FB7EC6.4020107@martos.bme.hu> <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> <20140213221543.GZ1342@hendrix.redhat.com> Message-ID: <52FD5407.2070506@redhat.com> On 02/13/2014 06:04 PM, Steve Dainard wrote: > I don't think this is an issue of bugs or documentation, more of > design. Perhaps there's someplace other than a users list this belongs > in but: > > If IPA is a centrally managed identity and access control system, > should these configurations not be passed to clients, rather than > every client needing configuration changes post join? Obviously I can > automate config changes, but why would I want to? I don't think > sudoers priv is a fringe case, its pretty much THE case for > access/admin control. I cringe to compare to a Windows domain, but I > don't have to manually tell a domain client that it should respect the > rules I set on a domain controller, I joined it to the domain for this > reason. > > Maybe you're working towards this, but in the meantime it would be > great if the options existed in the config files so we immediately > know what options are available and can comment/uncomment them rather > than searching around man pages for options that might exist. > > I believe you were looking for a documentation bug: > > # man sssd-sudo > To enable SSSD as a source for sudo rules, *add sss to the > sudoers entry* in nsswitch.conf(5). > > For example, to configure sudo to first lookup rules in the > standard sudoers(5) file (which > should contain rules that apply to local users) and then in > SSSD, the nsswitch.conf file > should contain the following line: > > * sudoers: files sss* > > # /etc/nsswitch.conf > # > # An example Name Service Switch config file. This file should be > # sorted with the most-used services at the beginning. > # > # The entry '[NOTFOUND=return]' means that the search for an > # entry should stop if the search in the previous entry turned > # up nothing. Note that if the search failed due to some other reason > # (like no NIS server responding) then the search continues with the > # next entry. > # > # Valid entries include: > # > #nisplusUse NIS+ (NIS version 3) > #nisUse NIS (NIS version 2), also called YP > #dnsUse DNS (Domain Name Service) > #filesUse the local files > #dbUse the local database (.db) files > #compatUse NIS on compat mode > #hesiodUse Hesiod for user lookups > #[NOTFOUND=return]Stop searching if not found so far > # > > # To use db, put the "db" in front of "files" for entries you want to be > # looked up first in the databases > # > # Example: > #passwd: db files nisplus nis > #shadow: db files nisplus nis > #group: db files nisplus nis > > passwd: files sss > shadow: files sss > group: files sss > #initgroups: files > > #hosts: db files nisplus nis dns > hosts: files mdns4_minimal [NOTFOUND=return] 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 > > > > Entry does not exist. > > > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------------------------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or > confidential. If you are not the intended recipient, please delete the > e-mail and any attachments and notify us immediately. > > > On Thu, Feb 13, 2014 at 5:15 PM, Jakub Hrozek > wrote: > > On Thu, Feb 13, 2014 at 03:05:07PM -0500, Steve Dainard wrote: > > Is this server or client side where sudo_provider=ipa is > included in ver > > > 1.11.x? > > Client side (sssd) > > > > > My fedora 20 client doesn't have this option listed, or is it > baked in? > > > > Where exactly do you see the documentation lacking, perhaps the > sssd-ipa > man page, or the sssd-sudo man page? I agree that docs are important, > but my view might be skewed because I know the internals.. > > All that should be required with 1.9.6 or 1.11.x is: > sudo_provider=ipa > > And enabling the 'sss' module in /etc/nsswitch.conf: > sudoers: files sss > > That's it. Please let us know if you find any bugs in code or docs. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Managing configuration files is outside of scope of IPA or SSSD. We looked at this at the beginning of the IPA project a got a push back from administrators who are used to control their Linux infra via Puppet, Checf and similar means. We are also working on the OpenLMI provider for SSSD this would allow to introspect and potentially configure SSSD from the central console, may be even from IPA. But this is future. For now the expectation is that some configuration needs to be done manually or via some scripting. This is how things have always been. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 13 23:30:37 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Feb 2014 18:30:37 -0500 Subject: [Freeipa-users] Setting up sudo In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2273242@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E2273242@EXCHMB1-ELS.BWINC.local> Message-ID: <52FD559D.4090603@redhat.com> On 02/13/2014 06:23 PM, Todd Maugh wrote: > and If I am configuring the sud-ldap.conf > > > what should it look like does any one have an example? > You have two options. Sudo can be integrated with SSSD or not. If you want SUDO to be integrated then this should help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf If you want to use SUDO independently from sssd and connect directly to IPA from SUDO you need to configure sudo -ldap.conf and use some user to bind to IPA. This user should be configured in the file. See more details in the IPA docs: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#config-sudo-clients > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh > [tmaugh at boingo.com] > *Sent:* Thursday, February 13, 2014 3:17 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Setting up sudo > > the documentation is kinda vague on some parts > > from the documentation: > > Because the |sudo| information is not available anonymously over LDAP > by default, Identity Management defines a default |sudo| user, > |uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX|, which can be set in the > LDAP/|sudo| configuration file, |/etc/sud-ldap.conf|. > > so is this user supposed to already pre defined. or do I need to > create the user, and then modify them > > thanks > > -Todd > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 14 07:36:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Feb 2014 09:36:33 +0200 Subject: [Freeipa-users] authentication against compat In-Reply-To: References: <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> <20140213221543.GZ1342@hendrix.redhat.com> Message-ID: <20140214073633.GA27001@redhat.com> On Thu, 13 Feb 2014, Steve Dainard wrote: >I don't think this is an issue of bugs or documentation, more of design. >Perhaps there's someplace other than a users list this belongs in but: > >If IPA is a centrally managed identity and access control system, should >these configurations not be passed to clients, rather than every client >needing configuration changes post join? Obviously I can automate config >changes, but why would I want to? I don't think sudoers priv is a fringe >case, its pretty much THE case for access/admin control. I cringe to >compare to a Windows domain, but I don't have to manually tell a domain >client that it should respect the rules I set on a domain controller, I >joined it to the domain for this reason. When majority of expected features are already implemented, it is easy to fall into assumption that everything has to be complete from start. That's understandable but we are dealing with a living and evolving project where a feature addition often means integrating across multiple actual free software projects, all with their own priorities and schedules, step by step, or things will never happen. SUDO integration is not an exception here. First we needed to expand SUDO's support for external plugins. When SUDO data was placed in LDAP, it appeared that existing schema isn't really optimal, so FreeIPA schema was designed better (but incompatible with existing one from SUDO LDAP), but required a compatibility part to work with existing SUDO LDAP plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO LDAP schema as it gave SSSD wider coverage of SUDO support. Now we implemented support for native FreeIPA schema. The next step is to integrate configuration of it in ipa-client-install so that clients will get set up properly if there are SUDO rules configured on the server or ipa-client-install was actually given a bless from the admin (via CLI option or answering a question). It takes time and effort. Unsurprisingly, this is a relatively minor feature in the grand picture because we have dozens of such features all asking for attention and time, and our development teams are not expanding infinitely regardless how we all wished. :) Any help is welcome! -- / Alexander Bokovoy From mkosek at redhat.com Fri Feb 14 07:51:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 08:51:49 +0100 Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: <87eeeb84-5804-4e63-9a62-9bdd5a27dce5@prod190.prodesan.com.br> References: <87eeeb84-5804-4e63-9a62-9bdd5a27dce5@prod190.prodesan.com.br> Message-ID: <52FDCB15.9010508@redhat.com> On 02/13/2014 06:55 PM, Bruno Henrique Barbosa wrote: > > > > Hi everyone, > > > I've installed my IPA environment as it follows: > > > ipa01.example.com - master install > ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. > > > All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: > > > IPA Error 4203 > Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > > > > > Via command-line, debug-enabled: > > > root at ipa02's password: > Last login: Thu Feb 13 15:36:34 2014 > [root at ipa02 ~]# kinit admin > Password for admin at EXAMPLE.COM: > [root at ipa02 ~]# ipa-replica-manage list > ipa01.example.com: master > ipa02.example.com: master > [root at ipa02 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > > > Valid starting Expires Service principal > 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM > 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM > [root at ipa02 ~]# ipa -d user-add usertest > ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: args=klist -V > ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 > > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' > ipa: INFO: trying https://ipa02.example.com/ipa/xml > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 14 (0xe) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=EXAMPLE.COM > Validity: > Not Before: Qua Fev 12 19:42:11 2014 UTC > Not After: S?b Fev 13 19:42:11 2016 UTC > Subject: CN=ipa02.example.com,O=EXAMPLE.COM > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: > f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: > 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: > 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: > 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: > e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: > 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: > 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: > 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: > db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: > 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: > 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: > c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: > d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: > 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: > c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd > Exponent: > 65537 (0x10001) > Signed Extensions: (5) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: > c3:9c:48:63 > Serial Number: None > General Names: [0 total] > > > Name: Authority Information Access > Critical: False > > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > > Name: Certificate Subject Key ID > Critical: False > Data: > ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: > 55:7c:07:ec > > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: > 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: > f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: > 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: > 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: > 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: > f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: > 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: > 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: > df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: > f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: > 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: > 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: > bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: > c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: > 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 > Fingerprint (MD5): > 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf > Fingerprint (SHA1): > a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: > 66:6e:f7:77 > ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: Created connection context.xmlclient > First name: usertest > Last name: testname > ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) > ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) > ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl pupdate 227287872 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > > > > > Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! > > > Thank you for any help you can provide in this situation! > > > Bruno Henrique Barbosa > Jr. Sys Admin > IT Department > Santos City Hall Hello Bruno, I saw the logs you sent to Dmitri. It seems to me that the replication link is broken, thus replica DNA plugin cannot acquire DNA ranges from master, thus it has no available range, thus adding users fails as DS cannot allocate UID and GID. I think your replication will be broken as well, did you verify that users you delete/modify on replica are also deleted/modified on master? I think the root cause is this log: [13/Feb/2014:15:31:11 -0200] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa02.example.com at EXAMPLE.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Is your KDC running? [replica] # ipactl status You can also try to kinit manually to debug: [replica] # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa02.example.com at EXAMPLE.COM If it does not succeed, neither it'd succeed for the DS. I would also recommend checking that DNS is sane. You can find some pointers here: http://www.freeipa.org/page/Troubleshooting#DNS_Issues HTH, Martin From mkosek at redhat.com Fri Feb 14 08:09:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 09:09:59 +0100 Subject: [Freeipa-users] WebUI questions. In-Reply-To: <52FD1851.40705@redhat.com> References: <52FD1851.40705@redhat.com> Message-ID: <52FDCF57.7040607@redhat.com> On 02/13/2014 08:09 PM, Rob Crittenden wrote: > Brent Clark wrote: >> When I assign a user the role of "User Administrator", when they log >> into the WebUI, they can see all the role, dns, config, tab and links. DNS as well? It should be already hidden by default: https://fedorahosted.org/freeipa/ticket/2569 >> >> They should only see the necessary tabs and links that having that role >> requires and none of the extra stuff. >> >> Is there a way to limit when appears in the WebUI based on Role? > > Not yet, see https://fedorahosted.org/freeipa/ticket/217 > > rob Web UI is more or less just a UI to IPA LDAP instance. So even if you hide it in the UI, user could still see the data with LDAP browser. This is something we are working on and are fixing in 3.4, so that Administrator have more granularity in selecting who can see what data: https://fedorahosted.org/freeipa/ticket/3566 Martin From bruno-barbosa at prodesan.com.br Fri Feb 14 11:36:16 2014 From: bruno-barbosa at prodesan.com.br (Bruno Henrique Barbosa) Date: Fri, 14 Feb 2014 09:36:16 -0200 (BRST) Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: <52FDCB15.9010508@redhat.com> Message-ID: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> Hi Martin, thanks for the help. Yes, I already did that test. Created a user on ipa01 (master), then he appeared on ipa02 (replica), in the replica, I modified his email address, it appeared back on master. Still, I cannot create a brand new user (or POSIX group) on ipa02. [root at ipa01 ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root at ipa02 ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING Interesting on replica's /var/log/krb5kdc.log: [root at ipa02 ~]# cat /var/log/krb5kdc.log | grep "Feb 13 15:31" Feb 13 15:31:13 ipa02 krb5kdc[1524](info): setting up network... Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 6: udp 0.0.0.0.88 (pktinfo) Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 8: tcp 0.0.0.0.88 Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 7: tcp ::.88 Feb 13 15:31:13 ipa02 krb5kdc[1524](info): set up 3 sockets Feb 13 15:31:13 ipa02 krb5kdc[1525](info): creating 4 worker processes Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 7 Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 8 Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 6 Feb 13 15:31:13 ipa02 krb5kdc[1535](info): commencing operation Feb 13 15:31:13 ipa02 krb5kdc[1533](info): commencing operation Feb 13 15:31:13 ipa02 krb5kdc[1536](info): commencing operation Feb 13 15:31:13 ipa02 krb5kdc[1534](info): commencing operation Feb 13 15:31:14 ipa02 krb5kdc[1534](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Feb 13 15:31:14 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM Feb 13 15:31:14 ipa02 krb5kdc[1536](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for ldap/ipa01.example.com at EXAMPLE.COM Feb 13 15:31:28 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Feb 13 15:31:28 ipa02 krb5kdc[1535](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM Feb 13 15:31:28 ipa02 krb5kdc[1535](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for ldap/ipa02.example.com at EXAMPLE.COM Running kinit -kt on replica, returns nothing on prompt, but populates /var/log/krb5kdc.log with: Feb 14 09:34:05 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Feb 14 09:34:05 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392377645, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM DNS is OK, resolving FQDN of both master and replica forward and reverse. Bruno Henrique Barbosa Jr. Sys Admin IT Department Santos City Hall ----- Mensagem original ----- De: "Martin Kosek" Para: "Bruno Henrique Barbosa" , freeipa-users at redhat.com Enviadas: Sexta-feira, 14 de Fevereiro de 2014 5:51:49 Assunto: Re: [Freeipa-users] IPA Replica cannot add user On 02/13/2014 06:55 PM, Bruno Henrique Barbosa wrote: > > > > Hi everyone, > > > I've installed my IPA environment as it follows: > > > ipa01.example.com - master install > ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. > > > All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: > > > IPA Error 4203 > Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > > > > > Via command-line, debug-enabled: > > > root at ipa02's password: > Last login: Thu Feb 13 15:36:34 2014 > [root at ipa02 ~]# kinit admin > Password for admin at EXAMPLE.COM: > [root at ipa02 ~]# ipa-replica-manage list > ipa01.example.com: master > ipa02.example.com: master > [root at ipa02 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at EXAMPLE.COM > > > Valid starting Expires Service principal > 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM > 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM > [root at ipa02 ~]# ipa -d user-add usertest > ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: args=klist -V > ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 > > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' > ipa: INFO: trying https://ipa02.example.com/ipa/xml > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 14 (0xe) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=EXAMPLE.COM > Validity: > Not Before: Qua Fev 12 19:42:11 2014 UTC > Not After: S?b Fev 13 19:42:11 2016 UTC > Subject: CN=ipa02.example.com,O=EXAMPLE.COM > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: > f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: > 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: > 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: > 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: > e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: > 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: > 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: > 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: > db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: > 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: > 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: > c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: > d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: > 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: > c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd > Exponent: > 65537 (0x10001) > Signed Extensions: (5) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: > c3:9c:48:63 > Serial Number: None > General Names: [0 total] > > > Name: Authority Information Access > Critical: False > > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > > Name: Certificate Subject Key ID > Critical: False > Data: > ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: > 55:7c:07:ec > > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: > 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: > f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: > 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: > 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: > 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: > f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: > 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: > 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: > df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: > f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: > 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: > 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: > bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: > c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: > 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 > Fingerprint (MD5): > 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf > Fingerprint (SHA1): > a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: > 66:6e:f7:77 > ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > > ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: Created connection context.xmlclient > First name: usertest > Last name: testname > ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) > ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) > ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' > ipa: DEBUG: NSSConnection init ipa02.example.com > ipa: DEBUG: Connecting: 192.168.0.2:0 > ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 > ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM > ipa: DEBUG: stdout=227287872 > > > ipa: DEBUG: stderr= > ipa: DEBUG: args=keyctl pupdate 227287872 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. > > > > > Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! > > > Thank you for any help you can provide in this situation! > > > Bruno Henrique Barbosa > Jr. Sys Admin > IT Department > Santos City Hall Hello Bruno, I saw the logs you sent to Dmitri. It seems to me that the replication link is broken, thus replica DNA plugin cannot acquire DNA ranges from master, thus it has no available range, thus adding users fails as DS cannot allocate UID and GID. I think your replication will be broken as well, did you verify that users you delete/modify on replica are also deleted/modified on master? I think the root cause is this log: [13/Feb/2014:15:31:11 -0200] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa02.example.com at EXAMPLE.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Is your KDC running? [replica] # ipactl status You can also try to kinit manually to debug: [replica] # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa02.example.com at EXAMPLE.COM If it does not succeed, neither it'd succeed for the DS. I would also recommend checking that DNS is sane. You can find some pointers here: http://www.freeipa.org/page/Troubleshooting#DNS_Issues HTH, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 14 12:49:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Feb 2014 13:49:37 +0100 Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> References: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> Message-ID: <52FE10E1.7070205@redhat.com> Ok, this part seems ok then. I would then focus directly on DNA operation itself. DNA plugin says: [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_request_range: Error sending range extension extended operation request to server ipa01.example.com:389 [error 53] [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_pre_op: no more values available!! Error 53 should be Unwilling to perform. Are there any errors on master dirsrv errors log? Is any free number available on the master server? [master] $ ldapsearch -h `hostname` -D "cn=Directory Manager" -x -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' dnaNextValue dnaMaxValue Martin On 02/14/2014 12:36 PM, Bruno Henrique Barbosa wrote: > Hi Martin, thanks for the help. > > > Yes, I already did that test. Created a user on ipa01 (master), then he appeared on ipa02 (replica), in the replica, I modified his email address, it appeared back on master. Still, I cannot create a brand new user (or POSIX group) on ipa02. > > > > [root at ipa01 ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > > > > [root at ipa02 ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > > > > > Interesting on replica's /var/log/krb5kdc.log: > > > > [root at ipa02 ~]# cat /var/log/krb5kdc.log | grep "Feb 13 15:31" > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): setting up network... > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 6: udp 0.0.0.0.88 (pktinfo) > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 8: tcp 0.0.0.0.88 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 7: tcp ::.88 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): set up 3 sockets > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): creating 4 worker processes > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 7 > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 8 > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 6 > Feb 13 15:31:13 ipa02 krb5kdc[1535](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1533](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1536](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1534](info): commencing operation > Feb 13 15:31:14 ipa02 krb5kdc[1534](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 13 15:31:14 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > Feb 13 15:31:14 ipa02 krb5kdc[1536](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for ldap/ipa01.example.com at EXAMPLE.COM > > > Feb 13 15:31:28 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 13 15:31:28 ipa02 krb5kdc[1535](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > Feb 13 15:31:28 ipa02 krb5kdc[1535](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for ldap/ipa02.example.com at EXAMPLE.COM > > > > > Running kinit -kt on replica, returns nothing on prompt, but populates /var/log/krb5kdc.log with: > > > > > Feb 14 09:34:05 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 14 09:34:05 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392377645, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > > > DNS is OK, resolving FQDN of both master and replica forward and reverse. > > > > Bruno Henrique Barbosa > > Jr. Sys Admin > IT Department > Santos City Hall > ----- Mensagem original ----- > > De: "Martin Kosek" > Para: "Bruno Henrique Barbosa" , freeipa-users at redhat.com > Enviadas: Sexta-feira, 14 de Fevereiro de 2014 5:51:49 > Assunto: Re: [Freeipa-users] IPA Replica cannot add user > > On 02/13/2014 06:55 PM, Bruno Henrique Barbosa wrote: >> >> >> >> Hi everyone, >> >> >> I've installed my IPA environment as it follows: >> >> >> ipa01.example.com - master install >> ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. >> >> >> All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: >> >> >> IPA Error 4203 >> Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> >> >> >> >> Via command-line, debug-enabled: >> >> >> root at ipa02's password: >> Last login: Thu Feb 13 15:36:34 2014 >> [root at ipa02 ~]# kinit admin >> Password for admin at EXAMPLE.COM: >> [root at ipa02 ~]# ipa-replica-manage list >> ipa01.example.com: master >> ipa02.example.com: master >> [root at ipa02 ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at EXAMPLE.COM >> >> >> Valid starting Expires Service principal >> 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM >> 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM >> [root at ipa02 ~]# ipa -d user-add usertest >> ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' >> ipa: DEBUG: args=klist -V >> ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' >> ipa: INFO: trying https://ipa02.example.com/ipa/xml >> ipa: DEBUG: NSSConnection init ipa02.example.com >> ipa: DEBUG: Connecting: 192.168.0.2:0 >> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >> Data: >> Version: 3 (0x2) >> Serial Number: 14 (0xe) >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: CN=Certificate Authority,O=EXAMPLE.COM >> Validity: >> Not Before: Qua Fev 12 19:42:11 2014 UTC >> Not After: S?b Fev 13 19:42:11 2016 UTC >> Subject: CN=ipa02.example.com,O=EXAMPLE.COM >> Subject Public Key Info: >> Public Key Algorithm: >> Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: >> f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: >> 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: >> 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: >> 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: >> e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: >> 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: >> 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: >> 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: >> db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: >> 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: >> 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: >> c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: >> d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: >> 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: >> c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd >> Exponent: >> 65537 (0x10001) >> Signed Extensions: (5) >> Name: Certificate Authority Key Identifier >> Critical: False >> Key ID: >> 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: >> c3:9c:48:63 >> Serial Number: None >> General Names: [0 total] >> >> >> Name: Authority Information Access >> Critical: False >> >> >> Name: Certificate Key Usage >> Critical: True >> Usages: >> Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> >> Name: Extended Key Usage >> Critical: False >> Usages: >> TLS Web Server Authentication Certificate >> TLS Web Client Authentication Certificate >> >> >> Name: Certificate Subject Key ID >> Critical: False >> Data: >> ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: >> 55:7c:07:ec >> >> >> Signature: >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Signature: >> b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: >> 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: >> f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: >> 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: >> 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: >> 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: >> f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: >> 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: >> 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: >> df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: >> f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: >> 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: >> 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: >> bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: >> c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: >> 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 >> Fingerprint (MD5): >> 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf >> Fingerprint (SHA1): >> a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: >> 66:6e:f7:77 >> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >> ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" >> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >> ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' >> ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Created connection context.xmlclient >> First name: usertest >> Last name: testname >> ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >> ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >> ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' >> ipa: DEBUG: NSSConnection init ipa02.example.com >> ipa: DEBUG: Connecting: 192.168.0.2:0 >> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >> ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' >> ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: args=keyctl pupdate 227287872 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> >> >> >> >> Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! >> >> >> Thank you for any help you can provide in this situation! >> >> >> Bruno Henrique Barbosa >> Jr. Sys Admin >> IT Department >> Santos City Hall > > Hello Bruno, > > I saw the logs you sent to Dmitri. It seems to me that the replication link is > broken, thus replica DNA plugin cannot acquire DNA ranges from master, thus it > has no available range, thus adding users fails as DS cannot allocate UID and GID. > > I think your replication will be broken as well, did you verify that users you > delete/modify on replica are also deleted/modified on master? > > I think the root cause is this log: > > [13/Feb/2014:15:31:11 -0200] set_krb5_creds - Could not get initial credentials > for principal [ldap/ipa02.example.com at EXAMPLE.COM] in keytab > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested > realm) > > Is your KDC running? > > [replica] # ipactl status > > You can also try to kinit manually to debug: > > [replica] # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa02.example.com at EXAMPLE.COM > > If it does not succeed, neither it'd succeed for the DS. > > I would also recommend checking that DNS is sane. You can find some pointers here: > http://www.freeipa.org/page/Troubleshooting#DNS_Issues > > HTH, > Martin > > From sigbjorn at nixtra.com Fri Feb 14 13:32:08 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 14 Feb 2014 14:32:08 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52EBFA5C.4070601@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> Message-ID: <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> On Fri, January 31, 2014 20:32, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Fri, January 17, 2014 16:37, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> This worked better than expected. Thank you! :) >>>> >>>> >>>> >>>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays any certificates >>>> out of date, and all certificates in need of renewal within 28 days has been renewed. The >>>> webui also started working again and things seem to be back to normal. >>>> >>>> ipa03 however is still having issues. I could not renew any certificates on this server to >>>> begin with, but I managed to renew the certificates for the directory servers by changing >>>> the xmlrpc url to another ipa server in /etc/ipa/default.conf and resubmitting these >>>> requests. >>>> >>>> "getcert resubmit -i >>> NEED_GUIDANCE after a short while for the certificates for the PKI service. >>>> >>>> >>>> >>>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python: >>>> Updated certificate for ipaCert not available". >>>> >>>> >>>> >>>> There is a lot of information in the /var/log/pki-ca/debug, but nothing >>>> that I can easily distinguish as an error from all the other output. Anything in particular >>>> I >>>> should look for? >>> >>> Ok, so this is a bug in IPA related to python readline. Garbage is >>> getting inserted and causing bad things to happen, >>> https://fedorahosted.org/freeipa/ticket/4064 >>> >>> >>> >>> So the question is, are the certs available or not. >>> >>> >>> >>> A number of the same certificates are shared amongst all the CAs. One >>> does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs >>> refer to that location for an updated cert and will load them if they are updated. >>> >>> Look to see if the certs are updated there. Given that you have 2 >>> working masters I'm assuming that is the case, so it may just be a matter of fixing the >>> python. >>> >> >> I could not get anywhere even after manually patching the python script as mentioned in the >> ticket you provided. >> >> >> I ended up removing and re-adding the replica during a maintenance window. For future >> reference, what I did was to remove the replica as per the Identity Management Guide on >> docs.redhat.com. I then re-created the replica installation file and installed the replica. >> >> At this point Certmonger managed to retrieve new certificates for the expired certificates, but >> it kept segfaulting when it attempted to save the certificate to disk. I restarted certmonger a >> few times, but certmonger just ended up segfaulting over and over. I decided to block the ipa >> server off the network and change the date back to before the certs expired. After the date was >> changed I restarted certmonger. Certmonger managed to save the certs successfully this time and >> a "getcert list" now displays only certificates with an expire date of 2015 or 2016 and a status >> of MONTORING. >> >> >> I changed the date back to correct date and time and removed the iptables rules. The replica >> now works just fine. >> >> Thank you for your assistance. >> > > Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1032760 > It would seem like we're still encountering some issues. The date has now passed for when the old certificate expired, and the "ipa" cli command no longer works. The webui is still working just fine. These are the errors I receive. $ ipa user-find ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" ((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://serveripa03.example.com/ipa/xml, https://serveripa01.example.com/ipa/xml, https://serveripa02.example.com/ipa/xml I've been looking through the old threads on the list for similar issues, but these all seem to be related to the date expiring and the issue is fixed by changing the date back to before the certificate expired and request a new certificate - which is what we've done as well. A "getcert list" shows valid certificates on all 3 ipa servers. $ sudo getcert list|grep expires expires: 2016-01-24 20:15:34 UTC expires: 2015-12-28 14:25:19 UTC expires: 2015-12-28 14:25:56 UTC expires: 2015-12-28 14:25:56 UTC expires: 2016-01-13 20:21:26 UTC expires: 2016-01-24 20:15:32 UTC expires: 2016-01-24 20:15:35 UTC expires: 2015-12-28 14:25:56 UTC Somehow I seem to have 2 "Server-Cert" on ipa01. But would that affect all the servers? $ sudo certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI NO.EP.CORP.LOCAL IPA CA CT,C,C Signing-Cert u,u,u Server-Cert u,u,u Server-Cert u,u,u ipaCert u,u,u $ sudo certutil -L -d /etc/httpd/alias -n 'Server-Cert' ----snip---- Not Before: Thu Jan 19 19:46:07 2012 Not After : Sun Jan 19 19:46:07 2014 ----snip---- and ----snip---- Not Before: Tue Jan 07 14:28:46 2014 Not After : Fri Jan 08 14:28:46 2016 ----snip---- Any suggestions to where I should continue troubleshooting? Regards, Siggi From rcritten at redhat.com Fri Feb 14 14:29:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 09:29:22 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> Message-ID: <52FE2842.6040105@redhat.com> Sigbjorn Lie wrote: > > > It would seem like we're still encountering some issues. The date has now passed for when the old > certificate expired, and the "ipa" cli command no longer works. The webui is still working just > fine. > > These are the errors I receive. > > $ ipa user-find > ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the > user.) > ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the > user.) > ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" > ((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://serveripa03.example.com/ipa/xml, https://serveripa01.example.com/ipa/xml, > https://serveripa02.example.com/ipa/xml This seems more like a client-side issue. Can you confirm that /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb contains the CA? certutil -L -d /etc/pki/nssdb -n 'IPA CA' rob From sdainard at miovision.com Fri Feb 14 14:49:49 2014 From: sdainard at miovision.com (Steve Dainard) Date: Fri, 14 Feb 2014 09:49:49 -0500 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140214073633.GA27001@redhat.com> References: <52FB7F68.9030008@redhat.com> <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> <20140213221543.GZ1342@hendrix.redhat.com> <20140214073633.GA27001@redhat.com> Message-ID: Thanks for your responses, your points seem quite valid. I may have been blinded by my specific scenario (actual client machines / users rather than only backend). Also that I'm dealing with Ubuntu clients just makes the process a bit more frustrating (client sssd project isn't quite as stable as Fedora/EL - but I realize its a one-man show). All your hard work is much appreciated, and I think this is an awesome project that has long been needed. Unfortunately the only time I can dedicate is in testing as I await the RHEL 7 release. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Feb 14, 2014 at 2:36 AM, Alexander Bokovoy wrote: > On Thu, 13 Feb 2014, Steve Dainard wrote: > >> I don't think this is an issue of bugs or documentation, more of design. >> Perhaps there's someplace other than a users list this belongs in but: >> >> If IPA is a centrally managed identity and access control system, should >> these configurations not be passed to clients, rather than every client >> needing configuration changes post join? Obviously I can automate config >> changes, but why would I want to? I don't think sudoers priv is a fringe >> case, its pretty much THE case for access/admin control. I cringe to >> compare to a Windows domain, but I don't have to manually tell a domain >> client that it should respect the rules I set on a domain controller, I >> joined it to the domain for this reason. >> > When majority of expected features are already implemented, it is easy > to fall into assumption that everything has to be complete from start. > That's understandable but we are dealing with a living and evolving > project where a feature addition often means integrating across multiple > actual free software projects, all with their own priorities and > schedules, step by step, or things will never happen. > > SUDO integration is not an exception here. First we needed to expand > SUDO's support for external plugins. When SUDO data was placed in LDAP, > it appeared that existing schema isn't really optimal, so FreeIPA schema > was designed better (but incompatible with existing one from SUDO LDAP), > but required a compatibility part to work with existing SUDO LDAP > plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO > LDAP schema as it gave SSSD wider coverage of SUDO support. Now we > implemented support for native FreeIPA schema. The next step is to > integrate configuration of it in ipa-client-install so that clients will > get set up properly if there are SUDO rules configured on the server or > ipa-client-install was actually given a bless from the admin (via CLI > option or answering a question). > > It takes time and effort. Unsurprisingly, this is a relatively minor > feature in the grand picture because we have dozens of such features all > asking for attention and time, and our development teams are not > expanding infinitely regardless how we all wished. :) > > Any help is welcome! > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Fri Feb 14 15:00:56 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 14 Feb 2014 16:00:56 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52FE2842.6040105@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> Message-ID: <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> It would seem like we're still encountering some issues. The date has now passed for when the >> old certificate expired, and the "ipa" cli command no longer works. The webui is still working >> just fine. >> >> These are the errors I receive. >> >> >> $ ipa user-find >> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the >> user.) ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" >> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the >> user.) ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" >> ((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://serveripa03.example.com/ipa/xml, >> https://serveripa01.example.com/ipa/xml, >> https://serveripa02.example.com/ipa/xml >> > > This seems more like a client-side issue. Can you confirm that > /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb > contains the CA? > > certutil -L -d /etc/pki/nssdb -n 'IPA CA' > The CA seem to be available. I ran the command on ipa01. See below for the output. The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa command from a remote machine. ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" Validity: Not Before: Thu Jan 19 19:44:21 2012 Not After : Sun Jan 19 19:44:21 2020 Subject: "CN=Certificate Authority,O=EXAMPLE.COM" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: Regards, Siggi From rcritten at redhat.com Fri Feb 14 16:18:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 11:18:27 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> Message-ID: <52FE41D3.4070308@redhat.com> Sigbjorn Lie wrote: > > > > On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> >>> >>> It would seem like we're still encountering some issues. The date has now passed for when the >>> old certificate expired, and the "ipa" cli command no longer works. The webui is still working >>> just fine. >>> >>> These are the errors I receive. >>> >>> >>> $ ipa user-find >>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the >>> user.) ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" >>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the >>> user.) ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" >>> ((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://serveripa03.example.com/ipa/xml, >>> https://serveripa01.example.com/ipa/xml, >>> https://serveripa02.example.com/ipa/xml >>> >> >> This seems more like a client-side issue. Can you confirm that >> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >> contains the CA? >> >> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >> > > > The CA seem to be available. I ran the command on ipa01. See below for the output. > > The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa command > from a remote machine. > > > ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" > Validity: > Not Before: Thu Jan 19 19:44:21 2012 > Not After : Sun Jan 19 19:44:21 2020 > Subject: "CN=Certificate Authority,O=EXAMPLE.COM" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: Perhaps we can brute force things to see what is going on. We can pass some extra options to the ipa tool to get ultra verbose output: $ ipa -vv -e debug=True user-show admin The thing to do is to check the server that it is communicating with and check /var/log/httpd/errors to see if there is an equivalent error logged there. rob From bnordgren at fs.fed.us Fri Feb 14 16:32:21 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 14 Feb 2014 16:32:21 +0000 Subject: [Freeipa-users] IPA authentication vs. authorization Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68DC6F@001FSN2MPN1-045.001f.mgd2.msft.net> >If IPA is a centrally managed identity and access control system, Since this seems to be a philosophical/generalized point, may I interject my own experience? I view IPA as a means of managing identities, not as a means of centrally controlling access. Two reasons: * In our organization, the CIO takes care of the 30000+ windows office clones. I manage my own collection of exceptions to the common rule, disconnected from the corporate network and with an explicit disavowal of CIO support. The fewer assumptions made about the client, the better (e.g., don't assume an OS.). Also, I don't mind sharing my solution with others stuck in the same situation, but I don't want to manage other people's machines. It's also pretty hard to envision access rules which would be common to all machines for all owners in this "domain of exceptions". * We collaborate promiscuously. An identity solution should cast a wide net for users. As many people as possible should be using their "normal" passwords on my systems, and not be bugging me to create an account for them. But the authorization solution should not assume that remotely defined user attributes mean anything, nor should it assume all users will have a consistent set of attributes, nor should it assume the presence of semantically equivalent elements. The upshot is: pursue centralization of authorization, but please don't get obsessed by it. There is a lot of value to a "light touch". Tools to ease the management of cross-domain trusts (AD/IPA/Just Plain Kerberos) or which serve as identity gateways (LDAP/SAML SSO) are just as valuable to me, if not more, than tools to bring a specific OS under tighter management. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From shreerajkarulkar at yahoo.com Fri Feb 14 17:55:46 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Fri, 14 Feb 2014 09:55:46 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FCD9AD.5000502@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <20140208092932.GA11564@mail.corp.redhat.com> <1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> Message-ID: <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> The logs are attached here. I had a day off yesterday. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Thursday, February 13, 2014 6:41 AM, Rob Crittenden wrote: Shree wrote: > Ok, failed at the same stage, would you like the entire > /var/log/ipareplica-install.log. If yes, should I attach to the email? > > > > pa? ? ? ? : INFO? ? ? File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script >? ? ? return_value = main_function() > >? ? File "/usr/sbin/ipa-replica-install", line 467, in main >? ? ? (CA, cs) = cainstance.install_replica_ca(config) > >? ? File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 1604, in install_replica_ca >? ? ? subject_base=config.subject_base) > >? ? File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 617, in configure_instance >? ? ? self.start_creation(runtime=210) > >? ? File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation >? ? ? method() > >? ? File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 879, in __configure_instance >? ? ? raise RuntimeError('Configuration of CA failed') > > ipa? ? ? ? : INFO? ? The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > [root at ldap2 ~]# > We need to see the full /var/log/ipareplica-install.log and the debug log from /var/log/pki-ca. rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal wrote: > On 02/12/2014 04:57 PM, Shree wrote: >> If there aren't any other tests to perform, can I go ahead and >> uninstall the ipa client and configure this Vm as a replica? > > Thanks for trying. At least we know that certmonger can run by itself. > When you install replica please collect all the install logs. > Is SELinux on/off? > >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 1:40 PM, Shree >> wrote: >> "getcert list" returned a bunch of info, see below >> >> root at ldap2 ~]# getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20140206184920': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,...................... >> ............................. >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal >> wrote: >> On 02/12/2014 03:41 PM, Shree wrote: >>> So I uninstalled the ipa server and installed the client >>> (ipa-client-install) on the same VM pointing at the master and >>> everything seems to work OK. All the sudo rules etc. Are there any >>> tests I can do check connectivity that could be helpful before I >>> configure this as a "replica" again. >> Ask certmonger to get a certificate >> >>> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal >>> wrote: >>> On 02/12/2014 02:09 PM, Shree wrote: >>>> Rob >>>> I really appreciate your help, please bear with me. At this point I >>>> need to take you back to my? ipa-replica-install and what happened >>>> there. >>>> >>>> [1] My command: ipa-replica-install --setup-ca >>>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >>>>? This ended with a >>>> Done configuring NTP daemon (ntpd). >>>> A CA is already configured on this system. >>>> >>>> [2] So did a pkiremove with the following command >>>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>>> >>>> [3] Re ran the ipa-replica-install command in step 1 >>>> The install went a little further but ended below. >>>> >>>> Configuring directory server for the CA (pkids): Estimated time 30 >>>> seconds >>>>? [1/3]: creating directory server user >>>>? [2/3]: creating directory server instance >>>>? [3/3]: restarting directory server >>>> Done configuring directory server for the CA (pkids). >>>> ipa? : ERROR? certmonger failed starting to track certificate: >>>> Command '/usr/bin/ipa-getcert start-tracking -d >>>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero >>>> exit status 1 >>>> Configuring certificate server (pki-cad): Estimated time 3 minutes >>>> 30 seconds >>>>? [1/17]: creating certificate server user >>>>? [2/17]: creating pki-ca instance >>>>? [3/17]: configuring certificate server instance >>>> ipa? : CRITICAL failed to configure ca instance Command >>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>> ................. >>>> ........................... >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Configuration of CA failed >>>> >>>> If I skip the "--setup-ca" option then the replica gets created >>>> without any CA services. The "master" and "replica" are in sync but >>>> I am unable to run a ipa-client-install using? the replica. Now I >>>> need to fix this to get a replica in place correctly. >>>> >>>> >>>> Shreeraj >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden >>>> wrote: >>>> Shree wrote: >>>> > OK I thought CA is a part of IPA ? Below is from my master IPA server >>>> > >>>> > [root at ldap ~]# ipactl status >>>> > Directory Service: RUNNING >>>> > KDC Service: RUNNING >>>> > KPASSWD Service: RUNNING >>>> > MEMCACHE Service: RUNNING >>>> > HTTP Service: RUNNING >>>> > CA Service: RUNNING >>>> > [root at ldap ~]# >>>> > >>>> > I can certainly send you a log if needed. >>>> >>>> It is part of IPA but the IPA server talks to it, not the clients >>>> directly. >>>> >>>> I can only speculate what the client is doing without seeing the log >>>> files, but I suspect both masters are in DNS and IPA is trying to >>>> enroll >>>> to the initial master which isn't available. >>>> >>>> rob >>>> >>>> > Shreeraj >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> > >>>> > >>>> > Change is the only Constant ! >>>> > >>>> > >>>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >>>> > > wrote: >>>> > Shree wrote: >>>> >? > Peter >>>> >? > Actually I mentioned earlier that my clients are in a separate >>>> VLAN and >>>> >? > cannot access the master. We have made provisions for the >>>> master and the >>>> >? > replica to sync by opening the needed ports in the firewall. We >>>> have >>>> >? > also opened up ports between the clients and the replica. I >>>> have tested >>>> >? > the connectivity for these ports. >>>> >? > Perhaps you can tell me if what I am trying to achieve is even >>>> possible? >>>> >? > i.e >>>> >? > I seem to get stuck with making the replica with the "--setup-ca" >>>> >? > option. Wthout that option I am able to create a replica and >>>> have it in >>>> >? > sync with the master. However my ipa-client-install fails from >>>> clients >>>> >? > as they try looking for the master for CA part of the install. >>>> > >>>> > Clients don't talk to the CA, they talk to an IPA server which >>>> talks to >>>> > the CA. >>>> > >>>> > I think we need to see /var/log/ipaclient-install.log to see what is >>>> > going on. >>>> > >>>> > rob >>>> > >>>> >? > Shreeraj >>>> >? > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> >? > >>>> >? > >>>> >? > Change is the only Constant ! >>>> >? > >>>> >? > >>>> >? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >>>> >? > >>>> >> wrote: >>>> >? > On 11.2.2014 23:53, Shree wrote: >>>> >? > >>>> >? > > Following ports are opened between the >>>> >? > > 1) Between the master and the replica (bi directional) >>>> >? > > 2) client machine and the ipa replica (unidirectional). >>>> >? > > When the replica was up it worked fine as far as syncing was >>>> > concerned. >>>> >? > > >>>> >? > >? 80 tcp >>>> >? > >? 443 tcp >>>> >? > >? 389 tcp >>>> >? > >? 636 tcp >>>> >? > >? 88 tcp >>>> >? > >? 464 tcp >>>> >? > >? 88 udp >>>> >? > >? 464 udp >>>> >? > >? 123 udp >>>> >? > > >>>> >? > > Shreeraj >>>> >? > > >>>> >? > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> >? > > >>>> >? > > Change is the only Constant ! >>>> >? > > >>>> >? > > >>>> >? > > >>>> >? > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >>>> >>>> > > >>>> >? > >>>> >>> wrote: >>>> >? > > >>>> >? > > On 02/11/2014 05:05 PM, Shree wrote: >>>> >? > > Dimitri >>>> >? > >> Sorry some the mail landed in my SPAM folder. Let answer your >>>> >? > questions (thanks for your help man) >>>> >? > > Please republish it on the list. >>>> >? > > Do not reply to me directly. >>>> >? > > >>>> >? > > Did you set your first server with the CA? Does all ports >>>> that need >>>> >? > >? ? ? to be open in the firewall between primary or server are >>>> actually >>>> >? > > open? >>>> >? > > >>>> >? > > >>>> >? > > >>>> >? > >> >>>> >? > >> What I have done so far is uninstalled the replica and tried to >>>> >? > install it again using the "--setup-ca" option. Previously I had >>>> >? > failures and when I removed the "--setup-ca" option the >>>> installation >>>> >? > succeeded (in a way). I understand now that I really need to >>>> fix the CA >>>> >? > installation errors first. >>>> >? > >> >>>> >? > >> >>>> >? > >> 1)The workaround helped me go forward a bit but I got stuck >>>> at this >>>> >? > point see below >>>> >? > >> =========== >>>> >? > >> [1/3]: creating directory server user >>>> >? > >> [2/3]: creating directory server instance >>>> >? > >> [3/3]: restarting directory server >>>> >? > >> Done configuring directory server for the CA (pkids). >>>> >? > >> ipa? ? ? : ERROR? certmonger failed starting to track >>>> >? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>>> >? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >>>> >? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >>>> >? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned >>>> non-zero exit >>>> >? > status 1 >>>> >? > >> Configuring certificate server (pki-cad): Estimated time 3 >>>> minutes >>>> >? > 30 seconds >>>> >? > >> [1/17]: creating certificate server user >>>> >? > >> [2/17]: creating pki-ca instance >>>> >? > >> [3/17]: configuring certificate server instance >>>> >? > >> ipa? ? ? : CRITICAL failed to configure ca instance Command >>>> >? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>>> >? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir >>>> /tmp/tmp-ipJSsT >>>> >? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >>>> >? > >> =========== >>>> >? > >> 2) No we do not use IPA for a DNS server. >>>> >? > >> >>>> >? > >> >>>> >? > >> 3)The reason for this could be that I had installed the replica >>>> >? > without the "--setup-ca". >>>> >? > >> >>>> >? > >> Shreeraj >>>> >? > >> >>>> >? > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> >? > >> >>>> >? > >> >>>> >? > >> >>>> >? > >> Change is the only Constant ! >>>> >? > >> >>>> >? > >> >>>> >? > >> >>>> >? > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >>>> > >>> > >>>> >? > >>>> >>> wrote: >>>> >? > >> >>>> >? > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >>>> >? > >>> Shree wrote: >>>> >? > >>>> Lukas >>>> >? > >>>> Perhaps I should explain the design a bit and >>>> >? > >? ? ? ? see if FreeIPA even >>>> >? > >>>> supports this.Our replica is in a separate >>>> >? > > network and all the >>>> >? > >>>> appropriate ports are opened between the master >>>> >? > >? ? ? ? and the replica. The >>>> >? > >>>> "replica" got created successfully and is in >>>> >? > >? ? ? ? sync with the master >>>> >? > >>>> (except the CA services which I mentioned >>>> >? > > earlier) >>>> >? > >>>> Now,when I try to run ipa-client-install on >>>> >? > >? ? hosts in the new network >>>> >? > >>>> using the replica, it complains that about >>>> >? > > "Cannot contact any KDC for >>>> >? > >>>> realm". >>>> >? > >>>> I am wondering it my hosts in the new network >>>> >? > >? ? ? ? are trying to access the >>>> >? > >>>> "master" for certificates since the replica >>>> >? > >? ? ? ? does not have any CA >>>> >? > >>>> services running? I couldn't find any obvious >>>> >? > >? ? ? ? proof of this even running >>>> >? > >>>> the install in a debug mode. Do I need to open >>>> >? > >? ? ? ? ports between the new >>>> >? > >>>> hosts and the master for CA services? >>>> >? > >>>> At this point I cannot disable or move the >>>> >? > > master, it needs to function >>>> >? > >>>> in its location but I need >>>> >? > >>> >>>> >? > >>> No, the clients don't directly talk to the CA. >>>> >? > >>> >>>> >? > >>> You'd need to look in >>>> >? > > /var/log/ipaclient-install.log to see what KDC >>>> >? > >>> was found and we were trying to use. If you have >>>> >? > >? ? ? ? SRV records for both >>>> >? > >>> but we try to contact the hidden master this will >>>> >? > > happen. You can try >>>> >? > >>> specifying the server on the command-line with >>>> >? > > --server but this will >>>> >? > >>> be hardcoding things and make it less flexible >>>> >? > >? ? ? ? later. >>>> >? > >>> >>>> >? > >>> rob >>>> >? > >>> >>>> >? > >>>> Shreeraj >>>> >? > >>>> >>>> >? > > >>>> >? > >>>> > >>>> ---------------------------------------------------------------------------------------- >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> Change is the only Constant ! >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >>>> >? > > Slebodnik >>>> >? > >>>> >>>> > >>>> > >>>> >>> wrote: >>>> >? > >>>> On (06/02/14 18:33), Shree wrote: >>>> >? > >>>> >>>> >? > >>>>> First of all, the ipa-replica-install did >>>> >? > >? ? ? ? not allow me to use >>>> >? > >>>> the --setup-ca >>>> >? > >>>>> option complaining that a cert already >>>> >? > > exists, replicate creation was >>>> >? > >>>>> successful after I skipped the option. >>>> >? > >>>>> Seems like the replica is one except >>>> >? > >>>>> 1) There is no CA Service running on the >>>> >? > > replica (which I guess is >>>> >? > >>>> expected) >>>> >? > >>>>> and >>>> >? > >>>>> 2) I am unable to run ipa-client-install >>>> >? > > successfully on any clients >>>> >? > >>>> using >>>> >? > >>>>> the replica. (I don't have the option of >>>> >? > >? ? ? ? using the primary master as >>>> >? > >>>> it is >>>> >? > >>>>> configured in a segregated environment. >>>> >? > >? ? ? ? Only the master and replica >>>> >? > >>>> are >>>> >? > >>>>> allowed to sync. >>>> >? > >>>>> Debug shows it fails at >>>> >? > >>>>> >>>> >? > >>>>> ipa? ? ? ? : DEBUG stderr=kinit: Cannot >>>> >? > > contact any KDC for realm >>>> >? > >>>> 'mydomainname.com' while getting initial >>>> >? > > credentials >>>> >? > >>>> >>>> >? > >>>>> >>>> >? > >>>>> >>>> >? > >>>> >>>> >? > >>>> I was not able to install replica witch CA on >>>> >? > >? ? ? ? fedora 20, >>>> >? > >>>> Bug is already reported >>>> https://fedorahosted.org/pki/ticket/816 >>>> >? > >>>> >>>> >? > >>>> Guys from dogtag found a workaround >>>> >? > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >>>> >? > >>>> >>>> >? > >>>> Does it work for you? >>>> >? > >>>> >>>> >? > >>>> LS >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> >>>> >? > >>>> _______________________________________________ >>>> >? > >>>> Freeipa-users mailing list >>>> >? > >>>> Freeipa-users at redhat.com >>>> > >>>> > >>>> >> >>>> >? > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >? > >>>> >>>> >? > >>> >>>> >? > >>> _______________________________________________ >>>> >? > >>> Freeipa-users mailing list >>>> >? > >>> Freeipa-users at redhat.com >>>> > >>>> > >>>> >> >>>> > >>>> >? > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >? > >> >>>> >? > >> What server provides DNS capabilities to the clients? >>>> >? > >> Do you use IPA DNS or some other DNS? >>>> >? > >> Clients seem to not be able to see replica KDC and try >>>> >? > >? ? ? ? to access hidden >>>> >? > >> master but they can know about this master only via DNS. >>>> >? > >>>> >? > >>>> >? > Shree, make sure that command >>>> >? > $ dig -t SRV _kerberos._udp.ipa.example >>>> >? > on the client returns both IPA servers (in ANSWER section). >>>> >? > >>>> >? > -- >>>> >? > Petr^2 Spacek >>>> >? > >>>> >? > >>>> >? > >>>> >? > >>>> >? > >>>> >? > _______________________________________________ >>>> >? > Freeipa-users mailing list >>>> >? > Freeipa-users at redhat.com >>>> > >>>> >? > https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >? > >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> I suggest that you temporarily try to install a client in place of >>> the replica and see why it does not install. >>> The log above suggests that certmonger that is a part of the replica >>> fails to connect to the first master. We need to understand the >>> reason why it fails. Then we would be able to make your replica be a CA. >>> I suspect that CA related communication between replica and master is >>> not going through for some reasons. >>> The install log would be really helpful. >>> Please see >>> http://www.freeipa.org/page/Troubleshooting to collect the right logs. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/? >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/? >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/? > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 181964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: application/octet-stream Size: 78703 bytes Desc: not available URL: From rcritten at redhat.com Fri Feb 14 18:20:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 13:20:51 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <52FE5E83.70904@redhat.com> Shree wrote: > The logs are attached here. I had a day off yesterday. Is port 7389 open? I see you skip the connection check, what was failing? In the ipareplica-install log this is reported: Failed to setup the replication for cloning. And in the debug log: [12/Feb/2014:15:15:38][http-9445-2]: DatabasePanel setupReplication: java.io.IOException: consumer initialization failed. -1 - LDAP error: Can't contact LDAP server rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Thursday, February 13, 2014 6:41 AM, Rob Crittenden > wrote: > Shree wrote: > > Ok, failed at the same stage, would you like the entire > > /var/log/ipareplica-install.log. If yes, should I attach to the email? > > > > > > > > pa : INFO File > > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > > line 614, in run_script > > return_value = main_function() > > > > File "/usr/sbin/ipa-replica-install", line 467, in main > > (CA, cs) = cainstance.install_replica_ca(config) > > > > File > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > > 1604, in install_replica_ca > > subject_base=config.subject_base) > > > > File > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > > 617, in configure_instance > > self.start_creation(runtime=210) > > > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > > line 358, in start_creation > > method() > > > > File > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > > 879, in __configure_instance > > raise RuntimeError('Configuration of CA failed') > > > > ipa : INFO The ipa-replica-install command failed, > > exception: RuntimeError: Configuration of CA failed > > > > Your system may be partly configured. > > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > > Configuration of CA failed > > [root at ldap2 ~]# > > > > We need to see the full /var/log/ipareplica-install.log and the debug > log from /var/log/pki-ca. > > rob > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal > wrote: > > On 02/12/2014 04:57 PM, Shree wrote: > >> If there aren't any other tests to perform, can I go ahead and > >> uninstall the ipa client and configure this Vm as a replica? > > > > Thanks for trying. At least we know that certmonger can run by itself. > > When you install replica please collect all the install logs. > > Is SELinux on/off? > > > >> Shreeraj > >> > ---------------------------------------------------------------------------------------- > >> > >> > >> Change is the only Constant ! > >> > >> > >> On Wednesday, February 12, 2014 1:40 PM, Shree > >> > > > > wrote: > >> "getcert list" returned a bunch of info, see below > >> > >> root at ldap2 ~]# getcert list > >> Number of certificates and requests being tracked: 2. > >> Request ID '20140206184920': > >> status: MONITORING > >> stuck: no > >> key pair storage: > >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > >> certificate: > >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > >> Certificate DB' > >> CA: dogtag-ipa-retrieve-agent-submit > >> issuer: CN=Certificate Authority,...................... > >> ............................. > >> > >> Shreeraj > >> > ---------------------------------------------------------------------------------------- > >> > >> > >> Change is the only Constant ! > >> > >> > >> On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal > > > >> > wrote: > >> On 02/12/2014 03:41 PM, Shree wrote: > >>> So I uninstalled the ipa server and installed the client > >>> (ipa-client-install) on the same VM pointing at the master and > >>> everything seems to work OK. All the sudo rules etc. Are there any > >>> tests I can do check connectivity that could be helpful before I > >>> configure this as a "replica" again. > >> Ask certmonger to get a certificate > >> > >>> > >>> Shreeraj > >>> > ---------------------------------------------------------------------------------------- > >>> > >>> > >>> Change is the only Constant ! > >>> > >>> > >>> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal > >>> > > wrote: > >>> On 02/12/2014 02:09 PM, Shree wrote: > >>>> Rob > >>>> I really appreciate your help, please bear with me. At this point I > >>>> need to take you back to my ipa-replica-install and what happened > >>>> there. > >>>> > >>>> [1] My command: ipa-replica-install --setup-ca > >>>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck > >>>> This ended with a > >>>> Done configuring NTP daemon (ntpd). > >>>> A CA is already configured on this system. > >>>> > >>>> [2] So did a pkiremove with the following command > >>>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca > -force > >>>> > >>>> [3] Re ran the ipa-replica-install command in step 1 > >>>> The install went a little further but ended below. > >>>> > >>>> Configuring directory server for the CA (pkids): Estimated time 30 > >>>> seconds > >>>> [1/3]: creating directory server user > >>>> [2/3]: creating directory server instance > >>>> [3/3]: restarting directory server > >>>> Done configuring directory server for the CA (pkids). > >>>> ipa : ERROR certmonger failed starting to track certificate: > >>>> Command '/usr/bin/ipa-getcert start-tracking -d > >>>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > >>>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > >>>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero > >>>> exit status 1 > >>>> Configuring certificate server (pki-cad): Estimated time 3 minutes > >>>> 30 seconds > >>>> [1/17]: creating certificate server user > >>>> [2/17]: creating pki-ca instance > >>>> [3/17]: configuring certificate server instance > >>>> ipa : CRITICAL failed to configure ca instance Command > >>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > >>>> ................. > >>>> ........................... > >>>> Your system may be partly configured. > >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. > >>>> > >>>> Configuration of CA failed > >>>> > >>>> If I skip the "--setup-ca" option then the replica gets created > >>>> without any CA services. The "master" and "replica" are in sync but > >>>> I am unable to run a ipa-client-install using the replica. Now I > >>>> need to fix this to get a replica in place correctly. > >>>> > >>>> > >>>> Shreeraj > >>>> > ---------------------------------------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden > >>>> > > > wrote: > >>>> Shree wrote: > >>>> > OK I thought CA is a part of IPA ? Below is from my master IPA > server > >>>> > > >>>> > [root at ldap > ~]# ipactl status > >>>> > Directory Service: RUNNING > >>>> > KDC Service: RUNNING > >>>> > KPASSWD Service: RUNNING > >>>> > MEMCACHE Service: RUNNING > >>>> > HTTP Service: RUNNING > >>>> > CA Service: RUNNING > >>>> > [root at ldap > ~]# > >>>> > > >>>> > I can certainly send you a log if needed. > >>>> > >>>> It is part of IPA but the IPA server talks to it, not the clients > >>>> directly. > >>>> > >>>> I can only speculate what the client is doing without seeing the log > >>>> files, but I suspect both masters are in DNS and IPA is trying to > >>>> enroll > >>>> to the initial master which isn't available. > >>>> > >>>> rob > >>>> > >>>> > Shreeraj > >>>> > > >>>> > ---------------------------------------------------------------------------------------- > >>>> > > >>>> > > >>>> > Change is the only Constant ! > >>>> > > >>>> > > >>>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden > >>>> > > >> wrote: > >>>> > Shree wrote: > >>>> > > Peter > >>>> > > Actually I mentioned earlier that my clients are in a separate > >>>> VLAN and > >>>> > > cannot access the master. We have made provisions for the > >>>> master and the > >>>> > > replica to sync by opening the needed ports in the firewall. We > >>>> have > >>>> > > also opened up ports between the clients and the replica. I > >>>> have tested > >>>> > > the connectivity for these ports. > >>>> > > Perhaps you can tell me if what I am trying to achieve is even > >>>> possible? > >>>> > > i.e > >>>> > > I seem to get stuck with making the replica with the "--setup-ca" > >>>> > > option. Wthout that option I am able to create a replica and > >>>> have it in > >>>> > > sync with the master. However my ipa-client-install fails from > >>>> clients > >>>> > > as they try looking for the master for CA part of the install. > >>>> > > >>>> > Clients don't talk to the CA, they talk to an IPA server which > >>>> talks to > >>>> > the CA. > >>>> > > >>>> > I think we need to see /var/log/ipaclient-install.log to see what is > >>>> > going on. > >>>> > > >>>> > rob > >>>> > > >>>> > > Shreeraj > >>>> > > > >>>> > > >>>> > ---------------------------------------------------------------------------------------- > >>>> > > > >>>> > > > >>>> > > Change is the only Constant ! > >>>> > > > >>>> > > > >>>> > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek > >>>> > > > > > >>>> > >>> wrote: > >>>> > > On 11.2.2014 23:53, Shree wrote: > >>>> > > > >>>> > > > Following ports are opened between the > >>>> > > > 1) Between the master and the replica (bi directional) > >>>> > > > 2) client machine and the ipa replica (unidirectional). > >>>> > > > When the replica was up it worked fine as far as syncing was > >>>> > concerned. > >>>> > > > > >>>> > > > 80 tcp > >>>> > > > 443 tcp > >>>> > > > 389 tcp > >>>> > > > 636 tcp > >>>> > > > 88 tcp > >>>> > > > 464 tcp > >>>> > > > 88 udp > >>>> > > > 464 udp > >>>> > > > 123 udp > >>>> > > > > >>>> > > > Shreeraj > >>>> > > > > >>>> > > > >>>> > > >>>> > ---------------------------------------------------------------------------------------- > >>>> > > > > >>>> > > > Change is the only Constant ! > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal > >>>> > > >>>> > > >> > >>>> > > > > > >>>> > >>>> wrote: > >>>> > > > > >>>> > > > On 02/11/2014 05:05 PM, Shree wrote: > >>>> > > > Dimitri > >>>> > > >> Sorry some the mail landed in my SPAM folder. Let answer your > >>>> > > questions (thanks for your help man) > >>>> > > > Please republish it on the list. > >>>> > > > Do not reply to me directly. > >>>> > > > > >>>> > > > Did you set your first server with the CA? Does all ports > >>>> that need > >>>> > > > to be open in the firewall between primary or server are > >>>> actually > >>>> > > > open? > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > >> > >>>> > > >> What I have done so far is uninstalled the replica and > tried to > >>>> > > install it again using the "--setup-ca" option. Previously I had > >>>> > > failures and when I removed the "--setup-ca" option the > >>>> installation > >>>> > > succeeded (in a way). I understand now that I really need to > >>>> fix the CA > >>>> > > installation errors first. > >>>> > > >> > >>>> > > >> > >>>> > > >> 1)The workaround helped me go forward a bit but I got stuck > >>>> at this > >>>> > > point see below > >>>> > > >> =========== > >>>> > > >> [1/3]: creating directory server user > >>>> > > >> [2/3]: creating directory server instance > >>>> > > >> [3/3]: restarting directory server > >>>> > > >> Done configuring directory server for the CA (pkids). > >>>> > > >> ipa : ERROR certmonger failed starting to track > >>>> > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > >>>> > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p > >>>> > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C > >>>> > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned > >>>> non-zero exit > >>>> > > status 1 > >>>> > > >> Configuring certificate server (pki-cad): Estimated time 3 > >>>> minutes > >>>> > > 30 seconds > >>>> > > >> [1/17]: creating certificate server user > >>>> > > >> [2/17]: creating pki-ca instance > >>>> > > >> [3/17]: configuring certificate server instance > >>>> > > >> ipa : CRITICAL failed to configure ca instance Command > >>>> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > >>>> > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir > >>>> /tmp/tmp-ipJSsT > >>>> > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - > >>>> > > >> =========== > >>>> > > >> 2) No we do not use IPA for a DNS server. > >>>> > > >> > >>>> > > >> > >>>> > > >> 3)The reason for this could be that I had installed the > replica > >>>> > > without the "--setup-ca". > >>>> > > >> > >>>> > > >> Shreeraj > >>>> > > >> > >>>> > > > >>>> > > >>>> > ---------------------------------------------------------------------------------------- > >>>> > > >> > >>>> > > >> > >>>> > > >> > >>>> > > >> Change is the only Constant ! > >>>> > > >> > >>>> > > >> > >>>> > > >> > >>>> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal > >>>> > > > > > >>>> >> > >>>> > > > > > >>>> > >>>> wrote: > >>>> > > >> > >>>> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: > >>>> > > >>> Shree wrote: > >>>> > > >>>> Lukas > >>>> > > >>>> Perhaps I should explain the design a bit and > >>>> > > > see if FreeIPA even > >>>> > > >>>> supports this.Our replica is in a separate > >>>> > > > network and all the > >>>> > > >>>> appropriate ports are opened between the master > >>>> > > > and the replica. The > >>>> > > >>>> "replica" got created successfully and is in > >>>> > > > sync with the master > >>>> > > >>>> (except the CA services which I mentioned > >>>> > > > earlier) > >>>> > > >>>> Now,when I try to run ipa-client-install on > >>>> > > > hosts in the new network > >>>> > > >>>> using the replica, it complains that about > >>>> > > > "Cannot contact any KDC for > >>>> > > >>>> realm". > >>>> > > >>>> I am wondering it my hosts in the new network > >>>> > > > are trying to access the > >>>> > > >>>> "master" for certificates since the replica > >>>> > > > does not have any CA > >>>> > > >>>> services running? I couldn't find any obvious > >>>> > > > proof of this even running > >>>> > > >>>> the install in a debug mode. Do I need to open > >>>> > > > ports between the new > >>>> > > >>>> hosts and the master for CA services? > >>>> > > >>>> At this point I cannot disable or move the > >>>> > > > master, it needs to function > >>>> > > >>>> in its location but I need > >>>> > > >>> > >>>> > > >>> No, the clients don't directly talk to the CA. > >>>> > > >>> > >>>> > > >>> You'd need to look in > >>>> > > > /var/log/ipaclient-install.log to see what KDC > >>>> > > >>> was found and we were trying to use. If you have > >>>> > > > SRV records for both > >>>> > > >>> but we try to contact the hidden master this will > >>>> > > > happen. You can try > >>>> > > >>> specifying the server on the command-line with > >>>> > > > --server but this will > >>>> > > >>> be hardcoding things and make it less flexible > >>>> > > > later. > >>>> > > >>> > >>>> > > >>> rob > >>>> > > >>> > >>>> > > >>>> Shreeraj > >>>> > > >>>> > >>>> > > > > >>>> > > > >>>> > > >>>> > ---------------------------------------------------------------------------------------- > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> Change is the only Constant ! > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas > >>>> > > > Slebodnik > >>>> > > >>>> > > > >>>> > >> > >>>> > > > > >>>> > >>>> wrote: > >>>> > > >>>> On (06/02/14 18:33), Shree wrote: > >>>> > > >>>> > >>>> > > >>>>> First of all, the ipa-replica-install did > >>>> > > > not allow me to use > >>>> > > >>>> the --setup-ca > >>>> > > >>>>> option complaining that a cert already > >>>> > > > exists, replicate creation was > >>>> > > >>>>> successful after I skipped the option. > >>>> > > >>>>> Seems like the replica is one except > >>>> > > >>>>> 1) There is no CA Service running on the > >>>> > > > replica (which I guess is > >>>> > > >>>> expected) > >>>> > > >>>>> and > >>>> > > >>>>> 2) I am unable to run ipa-client-install > >>>> > > > successfully on any clients > >>>> > > >>>> using > >>>> > > >>>>> the replica. (I don't have the option of > >>>> > > > using the primary master as > >>>> > > >>>> it is > >>>> > > >>>>> configured in a segregated environment. > >>>> > > > Only the master and replica > >>>> > > >>>> are > >>>> > > >>>>> allowed to sync. > >>>> > > >>>>> Debug shows it fails at > >>>> > > >>>>> > >>>> > > >>>>> ipa : DEBUG stderr=kinit: Cannot > >>>> > > > contact any KDC for realm > >>>> > > >>>> 'mydomainname.com' while getting initial > >>>> > > > credentials > >>>> > > >>>> > >>>> > > >>>>> > >>>> > > >>>>> > >>>> > > >>>> > >>>> > > >>>> I was not able to install replica witch CA on > >>>> > > > fedora 20, > >>>> > > >>>> Bug is already reported > >>>> https://fedorahosted.org/pki/ticket/816 > >>>> > > >>>> > >>>> > > >>>> Guys from dogtag found a workaround > >>>> > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 > >>>> > > >>>> > >>>> > > >>>> Does it work for you? > >>>> > > >>>> > >>>> > > >>>> LS > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> > >>>> > > >>>> _______________________________________________ > >>>> > > >>>> Freeipa-users mailing list > >>>> > > >>>> Freeipa-users at redhat.com > > > >>>> > >> > >>>> > > > >>>> > >>> > >>>> > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > > >>>> > >>>> > > >>> > >>>> > > >>> _______________________________________________ > >>>> > > >>> Freeipa-users mailing list > >>>> > > >>> Freeipa-users at redhat.com > > > >>>> > >> > >>>> > > > >>>> > >>> > >>>> > > >>>> > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > > >> > >>>> > > >> What server provides DNS capabilities to the clients? > >>>> > > >> Do you use IPA DNS or some other DNS? > >>>> > > >> Clients seem to not be able to see replica KDC and try > >>>> > > > to access hidden > >>>> > > >> master but they can know about this master only via DNS. > >>>> > > > >>>> > > > >>>> > > Shree, make sure that command > >>>> > > $ dig -t SRV _kerberos._udp.ipa.example > >>>> > > on the client returns both IPA servers (in ANSWER section). > >>>> > > > >>>> > > -- > >>>> > > Petr^2 Spacek > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > _______________________________________________ > >>>> > > Freeipa-users mailing list > >>>> > > Freeipa-users at redhat.com > > > >>>> > >> > >>>> > > https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> > > > >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Freeipa-users mailing list > >>>> Freeipa-users at redhat.com > > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> I suggest that you temporarily try to install a client in place of > >>> the replica and see why it does not install. > >>> The log above suggests that certmonger that is a part of the replica > >>> fails to connect to the first master. We need to understand the > >>> reason why it fails. Then we would be able to make your replica be > a CA. > >>> I suspect that CA related communication between replica and master is > >>> not going through for some reasons. > >>> The install log would be really helpful. > >>> Please see > >>> http://www.freeipa.org/page/Troubleshooting > to collect the right logs. > >>> > >>> -- > >>> Thank you, > >>> Dmitri Pal > >>> > >>> Sr. Engineering Manager for IdM portfolio > >>> Red Hat Inc. > >>> > >>> > >>> ------------------------------- > >>> Looking to carve out IT costs? > >>> www.redhat.com/carveoutcosts/ > >>> > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager for IdM portfolio > >> Red Hat Inc. > >> > >> > >> ------------------------------- > >> Looking to carve out IT costs? > >> www.redhat.com/carveoutcosts/ > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > > > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > From shreerajkarulkar at yahoo.com Fri Feb 14 19:14:50 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Fri, 14 Feb 2014 11:14:50 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FE5E83.70904@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52F77815.1060100@redhat.com> <52F93875.60504@redhat.com> <1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> Message-ID: <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> 1) 7839 TCP is open between the master and replica, do I need 7389 udp also?? What about clients and replica? I have the following ports opened and tested between master and replica. --> 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP), 7389 (TCP) and? 88 (UDP)? 464 (UDP) Do I need any more ports opened, I have to work with another team to get this done, so it will help having all the information. 2)I see you skip the connection check, what was failing? :-- Yes my replica install fails unless I user --skip connection check. I have tested the connection with the ports mentioned during the install. 3) In the ipareplica-install log this is reported: Failed to setup the replication for cloning. :--- Yes but what is the solution? 4) And in the debug log: :- Also what is the solution for the Java.io error? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Friday, February 14, 2014 10:21 AM, Rob Crittenden wrote: Shree wrote: > The logs are attached here. I had a day off yesterday. Is port 7389 open? I see you skip the connection check, what was failing? In the ipareplica-install log this is reported: Failed to setup the replication for cloning. And in the debug log: [12/Feb/2014:15:15:38][http-9445-2]: DatabasePanel setupReplication: java.io.IOException: consumer initialization failed. -1? - LDAP error: Can't contact LDAP server rob > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Thursday, February 13, 2014 6:41 AM, Rob Crittenden > wrote: > Shree wrote: >? > Ok, failed at the same stage, would you like the entire >? > /var/log/ipareplica-install.log. If yes, should I attach to the email? >? > >? > >? > >? > pa? ? ? ? : INFO? ? ? File >? > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", >? > line 614, in run_script >? >? ? ? return_value = main_function() >? > >? >? File "/usr/sbin/ipa-replica-install", line 467, in main >? >? ? ? (CA, cs) = cainstance.install_replica_ca(config) >? > >? >? ? File >? > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line >? > 1604, in install_replica_ca >? >? ? ? subject_base=config.subject_base) >? > >? >? ? File >? > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line >? > 617, in configure_instance >? >? ? ? self.start_creation(runtime=210) >? > >? >? ? File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", >? > line 358, in start_creation >? >? ? ? method() >? > >? >? ? File >? > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line >? > 879, in __configure_instance >? >? ? ? raise RuntimeError('Configuration of CA failed') >? > >? > ipa? ? ? ? : INFO? ? The ipa-replica-install command failed, >? > exception: RuntimeError: Configuration of CA failed >? > >? > Your system may be partly configured. >? > Run /usr/sbin/ipa-server-install --uninstall to clean up. >? > >? > Configuration of CA failed >? > [root at ldap2 ~]# >? > > > We need to see the full /var/log/ipareplica-install.log and the debug > log from /var/log/pki-ca. > > rob > >? > Shreeraj >? > > ---------------------------------------------------------------------------------------- >? > >? > >? > Change is the only Constant ! >? > >? > >? > On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal > wrote: >? > On 02/12/2014 04:57 PM, Shree wrote: >? >> If there aren't any other tests to perform, can I go ahead and >? >> uninstall the ipa client and configure this Vm as a replica? >? > >? > Thanks for trying. At least we know that certmonger can run by itself. >? > When you install replica please collect all the install logs. >? > Is SELinux on/off? >? > >? >> Shreeraj >? >> > ---------------------------------------------------------------------------------------- >? >> >? >> >? >> Change is the only Constant ! >? >> >? >> >? >> On Wednesday, February 12, 2014 1:40 PM, Shree >? >> > > > > wrote: >? >> "getcert list" returned a bunch of info, see below >? >> >? >> root at ldap2 ~]# getcert list >? >> Number of certificates and requests being tracked: 2. >? >> Request ID '20140206184920': >? >> status: MONITORING >? >> stuck: no >? >> key pair storage: >? >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >? >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >? >> certificate: >? >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >? >> Certificate DB' >? >> CA: dogtag-ipa-retrieve-agent-submit >? >> issuer: CN=Certificate Authority,...................... >? >> ............................. >? >> >? >> Shreeraj >? >> > ---------------------------------------------------------------------------------------- >? >> >? >> >? >> Change is the only Constant ! >? >> >? >> >? >> On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal > > >? >> > wrote: >? >> On 02/12/2014 03:41 PM, Shree wrote: >? >>> So I uninstalled the ipa server and installed the client >? >>> (ipa-client-install) on the same VM pointing at the master and >? >>> everything seems to work OK. All the sudo rules etc. Are there any >? >>> tests I can do check connectivity that could be helpful before I >? >>> configure this as a "replica" again. >? >> Ask certmonger to get a certificate >? >> >? >>> >? >>> Shreeraj >? >>> > ---------------------------------------------------------------------------------------- >? >>> >? >>> >? >>> Change is the only Constant ! >? >>> >? >>> >? >>> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal >? >>> > > wrote: >? >>> On 02/12/2014 02:09 PM, Shree wrote: >? >>>> Rob >? >>>> I really appreciate your help, please bear with me. At this point I >? >>>> need to take you back to my? ipa-replica-install and what happened >? >>>> there. >? >>>> >? >>>> [1] My command: ipa-replica-install --setup-ca >? >>>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck >? >>>>? This ended with a >? >>>> Done configuring NTP daemon (ntpd). >? >>>> A CA is already configured on this system. >? >>>> >? >>>> [2] So did a pkiremove with the following command >? >>>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca > -force >? >>>> >? >>>> [3] Re ran the ipa-replica-install command in step 1 >? >>>> The install went a little further but ended below. >? >>>> >? >>>> Configuring directory server for the CA (pkids): Estimated time 30 >? >>>> seconds >? >>>>? [1/3]: creating directory server user >? >>>>? [2/3]: creating directory server instance >? >>>>? [3/3]: restarting directory server >? >>>> Done configuring directory server for the CA (pkids). >? >>>> ipa? : ERROR? certmonger failed starting to track certificate: >? >>>> Command '/usr/bin/ipa-getcert start-tracking -d >? >>>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >? >>>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >? >>>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero >? >>>> exit status 1 >? >>>> Configuring certificate server (pki-cad): Estimated time 3 minutes >? >>>> 30 seconds >? >>>>? [1/17]: creating certificate server user >? >>>>? [2/17]: creating pki-ca instance >? >>>>? [3/17]: configuring certificate server instance >? >>>> ipa? : CRITICAL failed to configure ca instance Command >? >>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >? >>>> ................. >? >>>> ........................... >? >>>> Your system may be partly configured. >? >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >? >>>> >? >>>> Configuration of CA failed >? >>>> >? >>>> If I skip the "--setup-ca" option then the replica gets created >? >>>> without any CA services. The "master" and "replica" are in sync but >? >>>> I am unable to run a ipa-client-install using? the replica. Now I >? >>>> need to fix this to get a replica in place correctly. >? >>>> >? >>>> >? >>>> Shreeraj >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> >? >>>> >? >>>> >? >>>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden >? >>>> > > > wrote: >? >>>> Shree wrote: >? >>>> > OK I thought CA is a part of IPA ? Below is from my master IPA > server >? >>>> > >? >>>> > [root at ldap > ~]# ipactl status >? >>>> > Directory Service: RUNNING >? >>>> > KDC Service: RUNNING >? >>>> > KPASSWD Service: RUNNING >? >>>> > MEMCACHE Service: RUNNING >? >>>> > HTTP Service: RUNNING >? >>>> > CA Service: RUNNING >? >>>> > [root at ldap > ~]# >? >>>> > >? >>>> > I can certainly send you a log if needed. >? >>>> >? >>>> It is part of IPA but the IPA server talks to it, not the clients >? >>>> directly. >? >>>> >? >>>> I can only speculate what the client is doing without seeing the log >? >>>> files, but I suspect both masters are in DNS and IPA is trying to >? >>>> enroll >? >>>> to the initial master which isn't available. >? >>>> >? >>>> rob >? >>>> >? >>>> > Shreeraj >? >>>> > >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> > >? >>>> > >? >>>> > Change is the only Constant ! >? >>>> > >? >>>> > >? >>>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden >? >>>> > > >> wrote: >? >>>> > Shree wrote: >? >>>> >? > Peter >? >>>> >? > Actually I mentioned earlier that my clients are in a separate >? >>>> VLAN and >? >>>> >? > cannot access the master. We have made provisions for the >? >>>> master and the >? >>>> >? > replica to sync by opening the needed ports in the firewall. We >? >>>> have >? >>>> >? > also opened up ports between the clients and the replica. I >? >>>> have tested >? >>>> >? > the connectivity for these ports. >? >>>> >? > Perhaps you can tell me if what I am trying to achieve is even >? >>>> possible? >? >>>> >? > i.e >? >>>> >? > I seem to get stuck with making the replica with the "--setup-ca" >? >>>> >? > option. Wthout that option I am able to create a replica and >? >>>> have it in >? >>>> >? > sync with the master. However my ipa-client-install fails from >? >>>> clients >? >>>> >? > as they try looking for the master for CA part of the install. >? >>>> > >? >>>> > Clients don't talk to the CA, they talk to an IPA server which >? >>>> talks to >? >>>> > the CA. >? >>>> > >? >>>> > I think we need to see /var/log/ipaclient-install.log to see what is >? >>>> > going on. >? >>>> > >? >>>> > rob >? >>>> > >? >>>> >? > Shreeraj >? >>>> >? > >? >>>> > >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> >? > >? >>>> >? > >? >>>> >? > Change is the only Constant ! >? >>>> >? > >? >>>> >? > >? >>>> >? > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek >? >>>> >? > > > >? >>>> > >>> wrote: >? >>>> >? > On 11.2.2014 23:53, Shree wrote: >? >>>> >? > >? >>>> >? > > Following ports are opened between the >? >>>> >? > > 1) Between the master and the replica (bi directional) >? >>>> >? > > 2) client machine and the ipa replica (unidirectional). >? >>>> >? > > When the replica was up it worked fine as far as syncing was >? >>>> > concerned. >? >>>> >? > > >? >>>> >? > >? 80 tcp >? >>>> >? > >? 443 tcp >? >>>> >? > >? 389 tcp >? >>>> >? > >? 636 tcp >? >>>> >? > >? 88 tcp >? >>>> >? > >? 464 tcp >? >>>> >? > >? 88 udp >? >>>> >? > >? 464 udp >? >>>> >? > >? 123 udp >? >>>> >? > > >? >>>> >? > > Shreeraj >? >>>> >? > > >? >>>> >? > >? >>>> > >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> >? > > >? >>>> >? > > Change is the only Constant ! >? >>>> >? > > >? >>>> >? > > >? >>>> >? > > >? >>>> >? > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal >? >>>> > >? >>>> > > >> >? >>>> >? > > > >? >>>> > >>>> wrote: >? >>>> >? > > >? >>>> >? > > On 02/11/2014 05:05 PM, Shree wrote: >? >>>> >? > > Dimitri >? >>>> >? > >> Sorry some the mail landed in my SPAM folder. Let answer your >? >>>> >? > questions (thanks for your help man) >? >>>> >? > > Please republish it on the list. >? >>>> >? > > Do not reply to me directly. >? >>>> >? > > >? >>>> >? > > Did you set your first server with the CA? Does all ports >? >>>> that need >? >>>> >? > >? ? ? to be open in the firewall between primary or server are >? >>>> actually >? >>>> >? > > open? >? >>>> >? > > >? >>>> >? > > >? >>>> >? > > >? >>>> >? > >> >? >>>> >? > >> What I have done so far is uninstalled the replica and > tried to >? >>>> >? > install it again using the "--setup-ca" option. Previously I had >? >>>> >? > failures and when I removed the "--setup-ca" option the >? >>>> installation >? >>>> >? > succeeded (in a way). I understand now that I really need to >? >>>> fix the CA >? >>>> >? > installation errors first. >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> 1)The workaround helped me go forward a bit but I got stuck >? >>>> at this >? >>>> >? > point see below >? >>>> >? > >> =========== >? >>>> >? > >> [1/3]: creating directory server user >? >>>> >? > >> [2/3]: creating directory server instance >? >>>> >? > >> [3/3]: restarting directory server >? >>>> >? > >> Done configuring directory server for the CA (pkids). >? >>>> >? > >> ipa? ? ? : ERROR? certmonger failed starting to track >? >>>> >? > certificate: Command '/usr/bin/ipa-getcert start-tracking -d >? >>>> >? > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p >? >>>> >? > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C >? >>>> >? > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned >? >>>> non-zero exit >? >>>> >? > status 1 >? >>>> >? > >> Configuring certificate server (pki-cad): Estimated time 3 >? >>>> minutes >? >>>> >? > 30 seconds >? >>>> >? > >> [1/17]: creating certificate server user >? >>>> >? > >> [2/17]: creating pki-ca instance >? >>>> >? > >> [3/17]: configuring certificate server instance >? >>>> >? > >> ipa? ? ? : CRITICAL failed to configure ca instance Command >? >>>> >? > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >? >>>> >? > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir >? >>>> /tmp/tmp-ipJSsT >? >>>> >? > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG - >? >>>> >? > >> =========== >? >>>> >? > >> 2) No we do not use IPA for a DNS server. >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> 3)The reason for this could be that I had installed the > replica >? >>>> >? > without the "--setup-ca". >? >>>> >? > >> >? >>>> >? > >> Shreeraj >? >>>> >? > >> >? >>>> >? > >? >>>> > >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> Change is the only Constant ! >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> >? >>>> >? > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal >? >>>> > > > > >? >>>> >> >? >>>> >? > > > >? >>>> > >>>> wrote: >? >>>> >? > >> >? >>>> >? > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote: >? >>>> >? > >>> Shree wrote: >? >>>> >? > >>>> Lukas >? >>>> >? > >>>> Perhaps I should explain the design a bit and >? >>>> >? > >? ? ? ? see if FreeIPA even >? >>>> >? > >>>> supports this.Our replica is in a separate >? >>>> >? > > network and all the >? >>>> >? > >>>> appropriate ports are opened between the master >? >>>> >? > >? ? ? ? and the replica. The >? >>>> >? > >>>> "replica" got created successfully and is in >? >>>> >? > >? ? ? ? sync with the master >? >>>> >? > >>>> (except the CA services which I mentioned >? >>>> >? > > earlier) >? >>>> >? > >>>> Now,when I try to run ipa-client-install on >? >>>> >? > >? ? hosts in the new network >? >>>> >? > >>>> using the replica, it complains that about >? >>>> >? > > "Cannot contact any KDC for >? >>>> >? > >>>> realm". >? >>>> >? > >>>> I am wondering it my hosts in the new network >? >>>> >? > >? ? ? ? are trying to access the >? >>>> >? > >>>> "master" for certificates since the replica >? >>>> >? > >? ? ? ? does not have any CA >? >>>> >? > >>>> services running? I couldn't find any obvious >? >>>> >? > >? ? ? ? proof of this even running >? >>>> >? > >>>> the install in a debug mode. Do I need to open >? >>>> >? > >? ? ? ports between the new >? >>>> >? > >>>> hosts and the master for CA services? >? >>>> >? > >>>> At this point I cannot disable or move the >? >>>> >? > > master, it needs to function >? >>>> >? > >>>> in its location but I need >? >>>> >? > >>> >? >>>> >? > >>> No, the clients don't directly talk to the CA. >? >>>> >? > >>> >? >>>> >? > >>> You'd need to look in >? >>>> >? > > /var/log/ipaclient-install.log to see what KDC >? >>>> >? > >>> was found and we were trying to use. If you have >? >>>> >? > >? ? ? ? SRV records for both >? >>>> >? > >>> but we try to contact the hidden master this will >? >>>> >? > > happen. You can try >? >>>> >? > >>> specifying the server on the command-line with >? >>>> >? > > --server but this will >? >>>> >? > >>> be hardcoding things and make it less flexible >? >>>> >? > >? ? ? ? later. >? >>>> >? > >>> >? >>>> >? > >>> rob >? >>>> >? > >>> >? >>>> >? > >>>> Shreeraj >? >>>> >? > >>>> >? >>>> >? > > >? >>>> >? > >? >>>> > >? >>>> > ---------------------------------------------------------------------------------------- >? >>>> > > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> Change is the only Constant ! >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas >? >>>> >? > > Slebodnik >? >>>> >? > >>>> > > >? >>>> > >> >? >>>> > > > >? >>>> > >>>> wrote: >? >>>> >? > >>>> On (06/02/14 18:33), Shree wrote: >? >>>> >? > >>>> >? >>>> >? > >>>>> First of all, the ipa-replica-install did >? >>>> >? > >? ? ? ? not allow me to use >? >>>> >? > >>>> the --setup-ca >? >>>> >? > >>>>> option complaining that a cert already >? >>>> >? > > exists, replicate creation was >? >>>> >? > >>>>> successful after I skipped the option. >? >>>> >? > >>>>> Seems like the replica is one except >? >>>> >? > >>>>> 1) There is no CA Service running on the >? >>>> >? > > replica (which I guess is >? >>>> >? > >>>> expected) >? >>>> >? > >>>>> and >? >>>> >? > >>>>> 2) I am unable to run ipa-client-install >? >>>> >? > > successfully on any clients >? >>>> >? > >>>> using >? >>>> >? > >>>>> the replica. (I don't have the option of >? >>>> >? > >? ? ? ? using the primary master as >? >>>> >? > >>>> it is >? >>>> >? > >>>>> configured in a segregated environment. >? >>>> >? > >? ? ? ? Only the master and replica >? >>>> >? > >>>> are >? >>>> >? > >>>>> allowed to sync. >? >>>> >? > >>>>> Debug shows it fails at >? >>>> >? > >>>>> >? >>>> >? > >>>>> ipa? ? ? ? : DEBUG stderr=kinit: Cannot >? >>>> >? > > contact any KDC for realm >? >>>> >? > >>>> 'mydomainname.com' while getting initial >? >>>> >? > > credentials >? >>>> >? > >>>> >? >>>> >? > >>>>> >? >>>> >? > >>>>> >? >>>> >? > >>>> >? >>>> >? > >>>> I was not able to install replica witch CA on >? >>>> >? > >? ? ? ? fedora 20, >? >>>> >? > >>>> Bug is already reported >? >>>> https://fedorahosted.org/pki/ticket/816 >? >>>> >? > >>>> >? >>>> >? > >>>> Guys from dogtag found a workaround >? >>>> >? > >>>> https://fedorahosted.org/pki/ticket/816#comment:12 >? >>>> >? > >>>> >? >>>> >? > >>>> Does it work for you? >? >>>> >? > >>>> >? >>>> >? > >>>> LS >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> >? >>>> >? > >>>> _______________________________________________ >? >>>> >? > >>>> Freeipa-users mailing list >? >>>> >? > >>>> Freeipa-users at redhat.com > > >? >>>> > >> >? >>>> > > >? >>>> > >>> >? >>>> >? > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >>>> >? > >>>> >? >>>> >? > >>> >? >>>> >? > >>> _______________________________________________ >? >>>> >? > >>> Freeipa-users mailing list >? >>>> >? > >>> Freeipa-users at redhat.com > > >? >>>> > >> >? >>>> > > >? >>>> > >>> >? >>>> > >? >>>> >? > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >>>> >? > >> >? >>>> >? > >> What server provides DNS capabilities to the clients? >? >>>> >? > >> Do you use IPA DNS or some other DNS? >? >>>> >? > >> Clients seem to not be able to see replica KDC and try >? >>>> >? > >? ? ? ? to access hidden >? >>>> >? > >> master but they can know about this master only via DNS. >? >>>> >? > >? >>>> >? > >? >>>> >? > Shree, make sure that command >? >>>> >? > $ dig -t SRV _kerberos._udp.ipa.example >? >>>> >? > on the client returns both IPA servers (in ANSWER section). >? >>>> >? > >? >>>> >? > -- >? >>>> >? > Petr^2 Spacek >? >>>> >? > >? >>>> >? > >? >>>> >? > >? >>>> >? > >? >>>> >? > >? >>>> >? > _______________________________________________ >? >>>> >? > Freeipa-users mailing list >? >>>> >? > Freeipa-users at redhat.com > > >? >>>> > >> >? >>>> >? > https://www.redhat.com/mailman/listinfo/freeipa-users >? >>>> > > >? >>>> > >? >>>> > >? >>>> > >? >>>> >? >>>> >? >>>> >? >>>> >? >>>> >? >>>> _______________________________________________ >? >>>> Freeipa-users mailing list >? >>>> Freeipa-users at redhat.com > > >? >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >>> I suggest that you temporarily try to install a client in place of >? >>> the replica and see why it does not install. >? >>> The log above suggests that certmonger that is a part of the replica >? >>> fails to connect to the first master. We need to understand the >? >>> reason why it fails. Then we would be able to make your replica be > a CA. >? >>> I suspect that CA related communication between replica and master is >? >>> not going through for some reasons. >? >>> The install log would be really helpful. >? >>> Please see >? >>> http://www.freeipa.org/page/Troubleshooting > to collect the right logs. >? >>> >? >>> -- >? >>> Thank you, >? >>> Dmitri Pal >? >>> >? >>> Sr. Engineering Manager for IdM portfolio >? >>> Red Hat Inc. >? >>> >? >>> >? >>> ------------------------------- >? >>> Looking to carve out IT costs? >? >>> www.redhat.com/carveoutcosts/? >? >>> >? >>> >? >>> >? >>> _______________________________________________ >? >>> Freeipa-users mailing list >? >>> Freeipa-users at redhat.com > > >? >>> https://www.redhat.com/mailman/listinfo/freeipa-users >? >>> >? >>> >? >> >? >> >? >> -- >? >> Thank you, >? >> Dmitri Pal >? >> >? >> Sr. Engineering Manager for IdM portfolio >? >> Red Hat Inc. >? >> >? >> >? >> ------------------------------- >? >> Looking to carve out IT costs? >? >> www.redhat.com/carveoutcosts/? >? >> >? >> >? >> >? >> >? >> >? >> _______________________________________________ >? >> Freeipa-users mailing list >? >> Freeipa-users at redhat.com > > >? >> https://www.redhat.com/mailman/listinfo/freeipa-users >? >> >? >> >? > >? > >? > -- >? > Thank you, >? > Dmitri Pal >? > >? > Sr. Engineering Manager for IdM portfolio >? > Red Hat Inc. >? > >? > >? > ------------------------------- >? > Looking to carve out IT costs? >? > www.redhat.com/carveoutcosts/? >? > >? > >? > >? > >? > >? > >? > _______________________________________________ >? > Freeipa-users mailing list >? > Freeipa-users at redhat.com >? > https://www.redhat.com/mailman/listinfo/freeipa-users >? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreerajkarulkar at yahoo.com Fri Feb 14 19:22:17 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Fri, 14 Feb 2014 11:22:17 -0800 (PST) Subject: [Freeipa-users] IPA Replica cannot add user In-Reply-To: <52FE10E1.7070205@redhat.com> References: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> <52FE10E1.7070205@redhat.com> Message-ID: <1392405737.4382.YahooMailNeo@web160104.mail.bf1.yahoo.com> I am going to follow this, I seem to have a similar problem, which is being discussed in a different email chain. Just in case you are interested it has "ipa-client-install fails on replica" in the subject line. I see that CA services are not running on your replica as well. The way I got there was skipping "--setup-ca" option which running the "ipa-replica-install". ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Friday, February 14, 2014 4:59 AM, Martin Kosek wrote: Ok, this part seems ok then. I would then focus directly on DNA operation itself. DNA plugin says: [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_request_range: Error sending range extension extended operation request to server ipa01.example.com:389 [error 53] [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_pre_op: no more values available!! Error 53 should be Unwilling to perform. Are there any errors on master dirsrv errors log? Is any free number available on the master server? [master] $ ldapsearch -h `hostname` -D "cn=Directory Manager" -x -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' dnaNextValue dnaMaxValue Martin On 02/14/2014 12:36 PM, Bruno Henrique Barbosa wrote: > Hi Martin, thanks for the help. > > > Yes, I already did that test. Created a user on ipa01 (master), then he appeared on ipa02 (replica), in the replica, I modified his email address, it appeared back on master. Still, I cannot create a brand new user (or POSIX group) on ipa02. > > > > [root at ipa01 ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > > > > [root at ipa02 ~]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > > > > > Interesting on replica's /var/log/krb5kdc.log: > > > > [root at ipa02 ~]# cat /var/log/krb5kdc.log | grep "Feb 13 15:31" > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): setting up network... > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 6: udp 0.0.0.0.88 (pktinfo) > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 8: tcp 0.0.0.0.88 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 7: tcp ::.88 > Feb 13 15:31:13 ipa02 krb5kdc[1524](info): set up 3 sockets > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): creating 4 worker processes > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 7 > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 8 > Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 6 > Feb 13 15:31:13 ipa02 krb5kdc[1535](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1533](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1536](info): commencing operation > Feb 13 15:31:13 ipa02 krb5kdc[1534](info): commencing operation > Feb 13 15:31:14 ipa02 krb5kdc[1534](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 13 15:31:14 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > Feb 13 15:31:14 ipa02 krb5kdc[1536](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for ldap/ipa01.example.com at EXAMPLE.COM > > > Feb 13 15:31:28 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 13 15:31:28 ipa02 krb5kdc[1535](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > Feb 13 15:31:28 ipa02 krb5kdc[1535](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for ldap/ipa02.example.com at EXAMPLE.COM > > > > > Running kinit -kt on replica, returns nothing on prompt, but populates /var/log/krb5kdc.log with: > > > > > Feb 14 09:34:05 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required > Feb 14 09:34:05 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392377645, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > > > DNS is OK, resolving FQDN of both master and replica forward and reverse. > > > > Bruno Henrique Barbosa > > Jr. Sys Admin > IT Department > Santos City Hall > ----- Mensagem original ----- > > De: "Martin Kosek" > Para: "Bruno Henrique Barbosa" , freeipa-users at redhat.com > Enviadas: Sexta-feira, 14 de Fevereiro de 2014 5:51:49 > Assunto: Re: [Freeipa-users] IPA Replica cannot add user > > On 02/13/2014 06:55 PM, Bruno Henrique Barbosa wrote: >> >> >> >> Hi everyone, >> >> >> I've installed my IPA environment as it follows: >> >> >> ipa01.example.com - master install >> ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. >> >> >> All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: >> >> >> IPA Error 4203 >> Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> >> >> >> >> Via command-line, debug-enabled: >> >> >> root at ipa02's password: >> Last login: Thu Feb 13 15:36:34 2014 >> [root at ipa02 ~]# kinit admin >> Password for admin at EXAMPLE.COM: >> [root at ipa02 ~]# ipa-replica-manage list >> ipa01.example.com: master >> ipa02.example.com: master >> [root at ipa02 ~]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at EXAMPLE.COM >> >> >> Valid starting Expires Service principal >> 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM >> 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM >> [root at ipa02 ~]# ipa -d user-add usertest >> ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' >> ipa: DEBUG: args=klist -V >> ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' >> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' >> ipa: INFO: trying https://ipa02.example.com/ipa/xml >> ipa: DEBUG: NSSConnection init ipa02.example.com >> ipa: DEBUG: Connecting: 192.168.0.2:0 >> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >> Data: >> Version: 3 (0x2) >> Serial Number: 14 (0xe) >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: CN=Certificate Authority,O=EXAMPLE.COM >> Validity: >> Not Before: Qua Fev 12 19:42:11 2014 UTC >> Not After: S?b Fev 13 19:42:11 2016 UTC >> Subject: CN=ipa02.example.com,O=EXAMPLE.COM >> Subject Public Key Info: >> Public Key Algorithm: >> Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: >> f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: >> 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: >> 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: >> 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: >> e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: >> 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: >> 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: >> 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: >> db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: >> 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: >> 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: >> c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: >> d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: >> 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: >> c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd >> Exponent: >> 65537 (0x10001) >> Signed Extensions: (5) >> Name: Certificate Authority Key Identifier >> Critical: False >> Key ID: >> 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: >> c3:9c:48:63 >> Serial Number: None >> General Names: [0 total] >> >> >> Name: Authority Information Access >> Critical: False >> >> >> Name: Certificate Key Usage >> Critical: True >> Usages: >> Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> >> Name: Extended Key Usage >> Critical: False >> Usages: >> TLS Web Server Authentication Certificate >> TLS Web Client Authentication Certificate >> >> >> Name: Certificate Subject Key ID >> Critical: False >> Data: >> ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: >> 55:7c:07:ec >> >> >> Signature: >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Signature: >> b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: >> 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: >> f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: >> 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: >> 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: >> 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: >> f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: >> 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: >> 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: >> df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: >> f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: >> 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: >> 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: >> bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: >> c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: >> 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 >> Fingerprint (MD5): >> 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf >> Fingerprint (SHA1): >> a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: >> 66:6e:f7:77 >> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >> ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" >> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >> ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' >> ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=keyctl_search: Required key not available >> >> >> ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Created connection context.xmlclient >> First name: usertest >> Last name: testname >> ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >> ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >> ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' >> ipa: DEBUG: NSSConnection init ipa02.example.com >> ipa: DEBUG: Connecting: 192.168.0.2:0 >> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >> ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' >> ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >> ipa: DEBUG: stdout=227287872 >> >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: args=keyctl pupdate 227287872 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >> >> >> >> >> Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! >> >> >> Thank you for any help you can provide in this situation! >> >> >> Bruno Henrique Barbosa >> Jr. Sys Admin >> IT Department >> Santos City Hall > > Hello Bruno, > > I saw the logs you sent to Dmitri. It seems to me that the replication link is > broken, thus replica DNA plugin cannot acquire DNA ranges from master, thus it > has no available range, thus adding users fails as DS cannot allocate UID and GID. > > I think your replication will be broken as well, did you verify that users you > delete/modify on replica are also deleted/modified on master? > > I think the root cause is this log: > > [13/Feb/2014:15:31:11 -0200] set_krb5_creds - Could not get initial credentials > for principal [ldap/ipa02.example.com at EXAMPLE.COM] in keytab > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested > realm) > > Is your KDC running? > > [replica] # ipactl status > > You can also try to kinit manually to debug: > > [replica] # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa02.example.com at EXAMPLE.COM > > If it does not succeed, neither it'd succeed for the DS. > > I would also recommend checking that DNS is sane. You can find some pointers here: > http://www.freeipa.org/page/Troubleshooting#DNS_Issues > > HTH, > Martin > > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 14 19:40:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Feb 2014 14:40:09 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <52FE7119.1070601@redhat.com> Shree wrote: > 1) 7839 TCP is open between the master and replica, do I need 7389 udp > also? What about clients and replica? > I have the following ports opened and tested between master and replica. > --> 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP), 7389 > (TCP) > and 88 (UDP) 464 (UDP) > Do I need any more ports opened, I have to work with another team to get > this done, so it will help having all the information. No, this list is enough. Still, it can't connect to it. Seeing the failure output from the connection check might be useful, or at least confirm the same. > 2)I see you skip the connection check, what was failing? :-- Yes my > replica install fails unless I user --skip connection check. I have > tested the connection with the ports mentioned during the install. I don't know what to say, the logs pretty clearly indicate that it can't connect on port 7389. > 3) In the ipareplica-install log this is reported: > > Failed to setup the replication for cloning. :--- Yes but what is the > solution? Fix the firewall. > > 4) And in the debug log: > > :- Also what is the solution for the Java.io error? Same thing. One failure cascades to another. rob From sdainard at miovision.com Fri Feb 14 21:33:07 2014 From: sdainard at miovision.com (Steve Dainard) Date: Fri, 14 Feb 2014 16:33:07 -0500 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt Message-ID: On a Ubuntu 13.10 client after configuring sssd to provide sudo service I left the client idle for a few hours. On returning, I unlocked the screensaver and did the following: sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: root at ubu1310:/home/miovision.corp/sdainard-admin# I haven't experienced this on a Fedora 20 or EL client so I'm guessing this is something specific to Ubuntu. I've attached the client sssd log if anyone can point me in the right direction. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ubu1310.sssd_miolinux.corp.log Type: text/x-log Size: 112532 bytes Desc: not available URL: From genadipost at gmail.com Fri Feb 14 22:14:58 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sat, 15 Feb 2014 00:14:58 +0200 Subject: [Freeipa-users] Issues creating trust with AD. Message-ID: I have seen threads where opened on trust issues: "AD - Freeipa trust confusion" "Cross domain trust" "Cannot loging via SSH with AD user TO IPA Domain" - which I opened. It looks like after creation of trust, TGT ticket can be issued from AD, but "su" and "ssh" do not allow a log in with AD user. I'm not sure if a conclusion has been reached on this subject. I gave it a try again and attempted to create a trust with IPA as a DNS subdomain of AD. I followed : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html AD domain: ADEXAMPLE.COM IPA subdoamin: LINUX.ADEXAMPLE.COM When i finished the necessary steps i attempted to retrieve a TGT from AD (while logged in to IPA server): [root at ipaserver1 sbin]# kinit Administrator at ADEXAMPLE.COM Password for Administrator at ADEXAMPLE.COM: [root at ipaserver1 sbin]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator at ADEXAMPLE.COM Valid starting Expires Service principal 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/ADEXAMPLE.COM at ADEXAMPLE.COM renew until 02/15/14 07:50:21 But logging in by "ssh" and "su" ended in failure: login as: Administrator at ADEXAMPLE.COM Administrator at ADDC.COM@192.168.227.201's password: Access denied After reading http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini did the following on the AD server: Administrative Tools -> Active Directory Domains and Trust -> adexample.com(right click) -> Properties -> Trust -> Domain Trusted by this domain (outgoing trust) -> Properties -> General -> Validate *After doing this i was able to login via "ssh" and "su" with "Administrator" **user :* login as: Administrator at ADEXAMPLE.COM Administrator at ADEXAMPLE.COM@192.168.227.201's password: Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 Could not chdir to home directory /home/adexample.com/administrator: No such file or directory /usr/bin/xauth: error in locking authority file /home/ adexample.com/administrator/.Xauthority -sh-4.1$ *But still not able to login with other AD accounts:* [root at ipaserver1 sbin]# su Genadi at ADEXAMPLE.COM su: user Genadi at ADEXAMPLE.COM does not exist After reading the other threads, ill try and provide as much information as i can: *wbinfo -u does not return values.* [root at ipaserver1 sbin]# wbinfo -u [root at ipaserver1 sbin]# *wbinfo -u output:* [root at ipaserver1 sbin]# wbinfo -g admins editors default smb group ad_users *wbinfo --online-status shows ADEXAMPLE is offline* [root at ipaserver1 ~]# wbinfo --online-status BUILTIN : online LINUX : online ADEXAMPLE : offline *getent for Administrator does return value.* [root at ipaserver1 sbin]# getent passwd Administrator at ADEXAMPLE.COM administrator at adexample.com:*:699000500:699000500::/home/ adexample.com/administrator: *getent for other AD users does not return value.* [root at ipaserver1 sbin]# getent passwd Genadi at ADEXAMPLE.COM [root at ipaserver1 sbin]# *System info/configurations:* [root at ipaserver1 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) [root at ipaserver1 sbin]# rpm -qa | grep ipa ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 libipa_hbac-python-1.9.2-129.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-trust-ad-3.0.0-37.el6.x86_64 libipa_hbac-1.9.2-129.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-37.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [root at ipaserver1 ~]# rpm -qa | grep sssd sssd-1.9.2-129.el6.x86_64 sssd-client-1.9.2-129.el6.x86_64 [root at ipaserver1 sbin]# rpm -qa | grep samb samba4-common-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 samba4-libs-4.0.0-60.el6_5.rc4.x86_64 samba4-python-4.0.0-60.el6_5.rc4.x86_64 samba4-4.0.0-60.el6_5.rc4.x86_64 samba4-client-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 *SSSD* [root at ipaserver1 ~]# cat /etc/sssd/sssd.conf [domain/linux.adexample.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.adexample.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaserver1.linux.adexample.com chpass_provider = ipa ipa_server = ipaserver1.linux.adexample.com ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa debug_level = 6 [sssd] services = nss, pam, ssh, pac config_file_version = 2 domains = linux.adexample.com debug_level = 6 [nss] debug_level = 6 [pam] debug_level = 6 [sudo] debug_level = 6 [autofs] debug_level = 6 [ssh] debug_level = 6 [pac] debug_level = 6 *KRB5* [root at ipaserver1 ~]# cat /etc/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 = LINUX.ADEXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] LINUX.ADEXAMPLE.COM = { kdc = ipaserver1.linux.adexample.com:88 master_kdc = ipaserver1.linux.adexample.com:88 admin_server = ipaserver1.linux.adexample.com:749 default_domain = linux.adexample.com pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ ADEXAMPLE.COM/@adexample.com/ auth_to_local = DEFAULT } [domain_realm] .linux.adexample.com = LINUX.ADEXAMPLE.COM linux.adexample.com = LINUX.ADEXAMPLE.COM [dbmodules] LINUX.ADEXAMPLE.COM = { db_library = ipadb.so } I have increased the debug level of the IPA components. Here are the logs (*krb5_child.log, **ldap_child.log, **log.smbd, **log.wb-ADEXAMPLE, **log.wb-LINUX, **log.winbindd, **log.winbindd-dc-connect, log.winbindd-idmap*, *sssd.log*, *sssd_linux.adexample.com.log*,*sssd_nss.log, **sssd_pac.log*, *sssd_pam.log, * *sssd_ssh.log, /var/log/secure):https://gist.github.com/anonymous/9006532 * Any insights on why only Administrator is recognized by the Trust? And why extra step on AD was needed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdainard at miovision.com Sun Feb 16 00:19:01 2014 From: sdainard at miovision.com (Steve Dainard) Date: Sat, 15 Feb 2014 19:19:01 -0500 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: References: Message-ID: Just experienced the same issue on Fedora 20: [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld [sudo] password for sdainard-admin at miovision.corp: sdainard-admin at miovision.corp is not allowed to run sudo on fed20. This incident will be reported. [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld [sudo] password for sdainard-admin at miovision.corp: [sdainard-admin at miovision.corp@fed20 ~]$ Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). /var/log/messages: Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall daemon... Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard wrote: > On a Ubuntu 13.10 client after configuring sssd to provide sudo service I > left the client idle for a few hours. On returning, I unlocked the > screensaver and did the following: > > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.corp/sdainard-admin# > > I haven't experienced this on a Fedora 20 or EL client so I'm guessing > this is something specific to Ubuntu. > > I've attached the client sssd log if anyone can point me in the right > direction. > > Thanks, > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | *Rethink Traffic* > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fed20.sssd_miolinux.corp.log Type: text/x-log Size: 61405 bytes Desc: not available URL: From regpm at mccleary.me.uk Sun Feb 16 11:48:45 2014 From: regpm at mccleary.me.uk (regpm at mccleary.me.uk) Date: Sun, 16 Feb 2014 11:48:45 +0000 Subject: [Freeipa-users] Kerberized NFS Mount Issues Message-ID: <5300A59D.1020807@mccleary.me.uk> Hi, I'm really stuck trying to get kerberized NFS configured via IPA and would be very grateful for any comments or advice based on the info I've provided below. I'm sure this is a very popular kerberized service configured under IPA and I must be missing something obvious. Thanks, Paul ### Background ### I've configured IPA (3.0.0-37.el6) on CentOS 6.5 (2.6.32-431.3.1.el6.x86_64) and have an NFS server and an NFS client (both also CentOS 6.5) configured and working as IPA clients, e.g. can login as an IPA LDAP user. I have tested plain NFSv4 and that works fine: Code: ------------------------------------------------------------------------ |*Testing Non-Kerberized NFS v4:* *##### ##### Client:* [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=sys nfs-server.example.local:/ /mnt mount.nfs4: timeout set for Sat Feb 15 23:58:23 2014 mount.nfs4: trying text-based options 'sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11' nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys) [root at nfs-client ~]# df -h /mnt Filesystem Size Used Avail Use% Mounted on nfs-server.example.local:/ 50G 14G 33G 30% /mnt [root at nfs-client ~]# mount|grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11) *##### ##### Server:* [root at nfs-server ~]# cat /etc/exports /pmtest 10.50.0.0/24(rw,sec=sys,fsid=0) [root at nfs-server ~]# exportfs -v /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,root_squash,no_all_squash)| ------------------------------------------------------------------------ When I try to mount using kerberos it fails. I've searched for a number of days and tried many things, but am still stuck. The key error I think is in the NFS server syslog: Code: ------------------------------------------------------------------------ |Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request| ------------------------------------------------------------------------ I don't understand how I have the wrong principal in the krb5.keytab. The various guides I've seen all have a similar keytab config as me, but I really hoped my first attempt using kerberos was going to be very easy as IPA would do all the hard stuff :-) ########################################################### *Output and Config Info From Failed Kerberized NFS mount:* Both client and server have secure NFS set to yes and name resolution is fine: Code: ------------------------------------------------------------------------ |[root at nfs-client ~]# nslookup nfs-server Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-server.example.local Address: 10.50.0.18 [root at nfs-client ~]# nslookup nfs-client Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-client.example.local Address: 10.50.0.11 [root at nfs-server ~]# nslookup nfs-server Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-server.example.local Address: 10.50.0.18 [root at nfs-server ~]# nslookup nfs-client Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-client.example.local Address: 10.50.0.11| ------------------------------------------------------------------------ Code: ------------------------------------------------------------------------ |*##### ##### Client:* [root at nfs-client ~]# service iptables status;getenforce iptables: Firewall is not running. Disabled Attempted mount: [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=krb5 nfs-server.example.local:/ /mnt mount.nfs4: timeout set for Sat Feb 15 23:45:23 2014 mount.nfs4: trying text-based options 'sec=krb5,addr=10.50.0.18,clientaddr=10.50.0.11' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting nfs-server.example.local:/ /var/log/messages: Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: process_krb5_upcall: service is '' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Successfully obtained machine credentials for principal 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' stored in ccache 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with any credentials cache for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: doing error downcall Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt0 /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.LOCAL dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true permitted_enctypes = des3-cbc-sha1 [realms] EXAMPLE.LOCAL = { kdc = ipa-server.example.local:88 master_kdc = ipa-server.example.local:88 admin_server = ipa-server.example.local:749 default_domain = example.local pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .example.local = EXAMPLE.LOCAL example.local = EXAMPLE.LOCAL /etc/krb5.keytab entries: [root at nfs-client ~]# klist -kte Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 4 02/15/14 23:27:51 host/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) 3 02/15/14 23:27:58 nfs/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) *##### ##### Server:* [root at nfs-server ~]# cat /etc/exports /pmtest 10.50.0.0/24(rw,sec=krb5,fsid=0) [root at nfs-server ~]# exportfs -v /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=krb5,rw,root_squash,no_all_squash) [root at nfs-server ~]# service iptables status;getenforce iptables: Firewall is not running. Disabled /var/log/messages: Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.LOCAL dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true permitted_enctypes = des3-cbc-sha1 [realms] EXAMPLE.LOCAL = { kdc = ipa-server.example.local:88 master_kdc = ipa-server.example.local:88 admin_server = ipa-server.example.local:749 default_domain = example.local pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .example.local = EXAMPLE.LOCAL example.local = EXAMPLE.LOCAL /etc/krb5.keytab entries: [root at nfs-server ~]# klist -kte Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 02/15/14 23:09:43 host/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) 3 02/15/14 23:09:51 nfs/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1)| -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sun Feb 16 19:14:03 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 16 Feb 2014 19:14:03 +0000 Subject: [Freeipa-users] Kerberized NFS Mount Issues In-Reply-To: <5300A59D.1020807@mccleary.me.uk> References: <5300A59D.1020807@mccleary.me.uk> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68DFFA@001FSN2MPN1-045.001f.mgd2.msft.net> I don't know if this is your issue, but I noticed this: Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache Who are you "kinit"ed as? Is your idmapper working on both client and server? Bryce From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of regpm at mccleary.me.uk Sent: Sunday, February 16, 2014 4:49 AM To: freeipa-users at redhat.com Cc: regpm at mccleary.me.uk Subject: [Freeipa-users] Kerberized NFS Mount Issues Hi, I'm really stuck trying to get kerberized NFS configured via IPA and would be very grateful for any comments or advice based on the info I've provided below. I'm sure this is a very popular kerberized service configured under IPA and I must be missing something obvious. Thanks, Paul ### Background ### I've configured IPA (3.0.0-37.el6) on CentOS 6.5 (2.6.32-431.3.1.el6.x86_64) and have an NFS server and an NFS client (both also CentOS 6.5) configured and working as IPA clients, e.g. can login as an IPA LDAP user. I have tested plain NFSv4 and that works fine: Code: ________________________________ Testing Non-Kerberized NFS v4: ##### ##### Client: [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=sys nfs-server.example.local:/ /mnt mount.nfs4: timeout set for Sat Feb 15 23:58:23 2014 mount.nfs4: trying text-based options 'sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11' nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys) [root at nfs-client ~]# df -h /mnt Filesystem Size Used Avail Use% Mounted on nfs-server.example.local:/ 50G 14G 33G 30% /mnt [root at nfs-client ~]# mount|grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11) ##### ##### Server: [root at nfs-server ~]# cat /etc/exports /pmtest 10.50.0.0/24(rw,sec=sys,fsid=0) [root at nfs-server ~]# exportfs -v /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,root_squash,no_all_squash) ________________________________ When I try to mount using kerberos it fails. I've searched for a number of days and tried many things, but am still stuck. The key error I think is in the NFS server syslog: Code: ________________________________ Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request ________________________________ I don't understand how I have the wrong principal in the krb5.keytab. The various guides I've seen all have a similar keytab config as me, but I really hoped my first attempt using kerberos was going to be very easy as IPA would do all the hard stuff :-) ########################################################### Output and Config Info From Failed Kerberized NFS mount: Both client and server have secure NFS set to yes and name resolution is fine: Code: ________________________________ [root at nfs-client ~]# nslookup nfs-server Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-server.example.local Address: 10.50.0.18 [root at nfs-client ~]# nslookup nfs-client Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-client.example.local Address: 10.50.0.11 [root at nfs-server ~]# nslookup nfs-server Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-server.example.local Address: 10.50.0.18 [root at nfs-server ~]# nslookup nfs-client Server: 10.50.0.20 Address: 10.50.0.20#53 Name: nfs-client.example.local Address: 10.50.0.11 ________________________________ Code: ________________________________ ##### ##### Client: [root at nfs-client ~]# service iptables status;getenforce iptables: Firewall is not running. Disabled Attempted mount: [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=krb5 nfs-server.example.local:/ /mnt mount.nfs4: timeout set for Sat Feb 15 23:45:23 2014 mount.nfs4: trying text-based options 'sec=krb5,addr=10.50.0.18,clientaddr=10.50.0.11' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting nfs-server.example.local:/ /var/log/messages: Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: process_krb5_upcall: service is '' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Successfully obtained machine credentials for principal 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' stored in ccache 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with any credentials cache for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: doing error downcall Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 Feb 15 23:43:23 nfs-client rpc.gssd[1123]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt0 /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.LOCAL dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true permitted_enctypes = des3-cbc-sha1 [realms] EXAMPLE.LOCAL = { kdc = ipa-server.example.local:88 master_kdc = ipa-server.example.local:88 admin_server = ipa-server.example.local:749 default_domain = example.local pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .example.local = EXAMPLE.LOCAL example.local = EXAMPLE.LOCAL /etc/krb5.keytab entries: [root at nfs-client ~]# klist -kte Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 4 02/15/14 23:27:51 host/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) 3 02/15/14 23:27:58 nfs/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) ##### ##### Server: [root at nfs-server ~]# cat /etc/exports /pmtest 10.50.0.0/24(rw,sec=krb5,fsid=0) [root at nfs-server ~]# exportfs -v /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=krb5,rw,root_squash,no_all_squash) [root at nfs-server ~]# service iptables status;getenforce iptables: Firewall is not running. Disabled /var/log/messages: Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.LOCAL dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true permitted_enctypes = des3-cbc-sha1 [realms] EXAMPLE.LOCAL = { kdc = ipa-server.example.local:88 master_kdc = ipa-server.example.local:88 admin_server = ipa-server.example.local:749 default_domain = example.local pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .example.local = EXAMPLE.LOCAL example.local = EXAMPLE.LOCAL /etc/krb5.keytab entries: [root at nfs-server ~]# klist -kte Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 02/15/14 23:09:43 host/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) 3 02/15/14 23:09:51 nfs/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mccleary.me.uk Sun Feb 16 20:34:50 2014 From: paul at mccleary.me.uk (Paul McCleary) Date: Sun, 16 Feb 2014 20:34:50 +0000 Subject: [Freeipa-users] Freeipa-users Digest, Vol 67, Issue 86 In-Reply-To: References: Message-ID: <530120EA.2070300@mccleary.me.uk> Hi Bryce, Much appreciate your response. In regard to idmapd - this is one of the things I had looked at. As both systems are in the same DNS domain it shouldn't be required according to: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-nfs.html But just in cased I set "Domain = example.local" in /etc/idmapd.conf on both NFS server and client. I also added ensured the FQDN for both NFS server and client is in /etc/hosts and /etc/sysconfig/network on both servers. rpc.idmapd is running on both client and server. I'm really not sure whether the following "warnings" are an issue or not? Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache You raise a good point regarding kinit - do I have to be kinit'ed in as anybody before trying to mount the share? I thought as the host and service principals are in the /etc/krb5.keytab I didn't need to specifically authenticate against the IPA server? - I might be showing a fundamental lack of knowledge on how this all works, so would be good if someone could confirm or clarify this. As I'd used ipa-getkeytab to refresh the krb5.keytab files I would have had a ticket for the admin IPA user. I re-tested anyway after specifically running kinit on both client (and server just for the hell of it): [root at nfs-client ~]# kinit Password for admin at EXAMPLE.LOCAL: [root at nfs-client ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at EXAMPLE.LOCAL Valid starting Expires Service principal 02/16/14 20:14:03 02/17/14 20:13:58 krbtgt/EXAMPLE.LOCAL at EXAMPLE.LOCAL [root at nfs-server ~]# kinit Password for admin at EXAMPLE.LOCAL: [root at nfs-server ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at EXAMPLE.LOCAL Valid starting Expires Service principal 02/16/14 20:18:40 02/17/14 20:18:38 krbtgt/EXAMPLE.LOCAL at EXAMPLE.LOCAL I tried the mount again and it still doesn't work; same error in the nfs-server log (and as per other output I put in my first message): Feb 16 20:28:53 bdsvn001 rpc.svcgssd[12405]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Feb 16 20:28:53 bdsvn001 rpc.svcgssd[12405]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Thanks, Paul On 16/02/2014 19:14, freeipa-users-request at redhat.com wrote: > 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: Kerberized NFS Mount Issues (Nordgren, Bryce L -FS) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Feb 2014 19:14:03 +0000 > From: "Nordgren, Bryce L -FS" > To: "regpm at mccleary.me.uk" , > "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Kerberized NFS Mount Issues > Message-ID: > <82E7C9A01FD0764CACDD35D10F5DFB6E68DFFA at 001FSN2MPN1-045.001f.mgd2.msft.net> > > Content-Type: text/plain; charset="us-ascii" > > I don't know if this is your issue, but I noticed this: > > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache > > Who are you "kinit"ed as? Is your idmapper working on both client and server? > > Bryce > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of regpm at mccleary.me.uk > Sent: Sunday, February 16, 2014 4:49 AM > To: freeipa-users at redhat.com > Cc: regpm at mccleary.me.uk > Subject: [Freeipa-users] Kerberized NFS Mount Issues > > Hi, > > I'm really stuck trying to get kerberized NFS configured via IPA and would be very grateful for any comments or advice based on the info I've provided below. I'm sure this is a very popular kerberized service configured under IPA and I must be missing something obvious. > > Thanks, Paul > > ### Background ### > I've configured IPA (3.0.0-37.el6) on CentOS 6.5 (2.6.32-431.3.1.el6.x86_64) and have an NFS server and an NFS client (both also CentOS 6.5) configured and working as IPA clients, e.g. can login as an IPA LDAP user. > > I have tested plain NFSv4 and that works fine: > Code: > ________________________________ > Testing Non-Kerberized NFS v4: > ##### > ##### > Client: > [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=sys nfs-server.example.local:/ /mnt > mount.nfs4: timeout set for Sat Feb 15 23:58:23 2014 > mount.nfs4: trying text-based options 'sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11' > nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys) > [root at nfs-client ~]# df -h /mnt > Filesystem Size Used Avail Use% Mounted on > nfs-server.example.local:/ 50G 14G 33G 30% /mnt > [root at nfs-client ~]# mount|grep nfs > sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) > nfsd on /proc/fs/nfsd type nfsd (rw) > nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11) > > ##### > ##### > Server: > [root at nfs-server ~]# cat /etc/exports > /pmtest 10.50.0.0/24(rw,sec=sys,fsid=0) > > [root at nfs-server ~]# exportfs -v > /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,root_squash,no_all_squash) > ________________________________ > When I try to mount using kerberos it fails. I've searched for a number of days and tried many things, but am still stuck. The key error I think is in the NFS server syslog: > Code: > ________________________________ > Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request > Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request > ________________________________ > I don't understand how I have the wrong principal in the krb5.keytab. The various guides I've seen all have a similar keytab config as me, but I really hoped my first attempt using kerberos was going to be very easy as IPA would do all the hard stuff :-) > > ########################################################### > Output and Config Info From Failed Kerberized NFS mount: > > Both client and server have secure NFS set to yes and name resolution is fine: > Code: > ________________________________ > [root at nfs-client ~]# nslookup nfs-server > Server: 10.50.0.20 > Address: 10.50.0.20#53 > > Name: nfs-server.example.local > Address: 10.50.0.18 > > [root at nfs-client ~]# nslookup nfs-client > Server: 10.50.0.20 > Address: 10.50.0.20#53 > > Name: nfs-client.example.local > Address: 10.50.0.11 > > > [root at nfs-server ~]# nslookup nfs-server > Server: 10.50.0.20 > Address: 10.50.0.20#53 > > Name: nfs-server.example.local > Address: 10.50.0.18 > > [root at nfs-server ~]# nslookup nfs-client > Server: 10.50.0.20 > Address: 10.50.0.20#53 > > Name: nfs-client.example.local > Address: 10.50.0.11 > ________________________________ > Code: > ________________________________ > ##### > ##### > Client: > [root at nfs-client ~]# service iptables status;getenforce > iptables: Firewall is not running. > Disabled > > Attempted mount: > [root at nfs-client ~]# mount -v -t nfs4 -o rw,sec=krb5 nfs-server.example.local:/ /mnt > mount.nfs4: timeout set for Sat Feb 15 23:45:23 2014 > mount.nfs4: trying text-based options 'sec=krb5,addr=10.50.0.18,clientaddr=10.50.0.11' > mount.nfs4: mount(2): Permission denied > mount.nfs4: access denied by server while mounting nfs-server.example.local:/ > > /var/log/messages: > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fac70 data 0x7fffaf4fab40 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: process_krb5_upcall: service is '' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Successfully obtained machine credentials for principal 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' stored in ccache 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-server.example.local' is 'nfs-server.example.local' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Full hostname for 'nfs-client.example.local' is 'nfs-client.example.local' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL while getting keytab entry for 'NFS-CLIENT.EXAMPLE.LOCAL$@EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: No key table entry found for root/nfs-client.example.local at EXAMPLE.LOCAL while getting keytab entry for 'root/nfs-client.example.local at EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: Success getting keytab entry for 'nfs/nfs-client.example.local at EXAMPLE.LOCAL' > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL' are good until 1392594203 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL as credentials cache for machine creds > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context using fsuid 0 (save_uid 0) > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating tcp client for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: DEBUG: port already set to 2049 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: creating context with server nfs at nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_EXAMPLE.LOCAL for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine krb5 context with any credentials cache for server nfs-server.example.local > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: doing error downcall > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 0x7fffaf4fa770 data 0x7fffaf4fa640 > Feb 15 23:43:23 nfs-client rpc.gssd[1123]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt0 > > /etc/krb5.conf > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = EXAMPLE.LOCAL > dns_lookup_realm = false > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > allow_weak_crypto = true > permitted_enctypes = des3-cbc-sha1 > > [realms] > EXAMPLE.LOCAL = { > kdc = ipa-server.example.local:88 > master_kdc = ipa-server.example.local:88 > admin_server = ipa-server.example.local:749 > default_domain = example.local > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .example.local = EXAMPLE.LOCAL > example.local = EXAMPLE.LOCAL > > /etc/krb5.keytab entries: > [root at nfs-client ~]# klist -kte > Keytab name: FILE:/etc/krb5.keytab > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 4 02/15/14 23:27:51 host/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) > 3 02/15/14 23:27:58 nfs/nfs-client.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) > > > ##### > ##### > Server: > [root at nfs-server ~]# cat /etc/exports > /pmtest 10.50.0.0/24(rw,sec=krb5,fsid=0) > > [root at nfs-server ~]# exportfs -v > /pmtest 10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=krb5,rw,root_squash,no_all_squash) > > [root at nfs-server ~]# service iptables status;getenforce > iptables: Firewall is not running. > Disabled > > > /var/log/messages: > Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request > Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request > > > /etc/krb5.conf > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = EXAMPLE.LOCAL > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > allow_weak_crypto = true > permitted_enctypes = des3-cbc-sha1 > > [realms] > EXAMPLE.LOCAL = { > kdc = ipa-server.example.local:88 > master_kdc = ipa-server.example.local:88 > admin_server = ipa-server.example.local:749 > default_domain = example.local > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .example.local = EXAMPLE.LOCAL > example.local = EXAMPLE.LOCAL > > > /etc/krb5.keytab entries: > [root at nfs-server ~]# klist -kte > Keytab name: FILE:/etc/krb5.keytab > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 2 02/15/14 23:09:43 host/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) > 3 02/15/14 23:09:51 nfs/nfs-server.example.local at EXAMPLE.LOCAL (des3-cbc-sha1) > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > -------------- 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 67, Issue 86 > ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sun Feb 16 23:10:58 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 16 Feb 2014 23:10:58 +0000 Subject: [Freeipa-users] Kerberized NFS Mount Issues Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E68E086@001FSN2MPN1-045.001f.mgd2.msft.net> >You raise a good point regarding kinit - do I have to be kinit'ed in as anybody >before trying to mount the share? I thought as the host and service principals >are in the /etc/krb5.keytab I didn't need to specifically authenticate against > the IPA server? - I might be showing a fundamental lack of knowledge on how > this all works, so would be good if someone could confirm or clarify this. The big feature of NFSv4 w/krb security is per-user authentication/authorization. NFSv4 with sec=sys (and all NFS <4) use host-based authorization. I'm pretty sure you should be able to mount the NFS export without 'kinit'ing, but I'm also pretty sure it should look empty (or even give you "permission denied" until you kinit to someone authorized to access it. I see you "kinit"ed to "admin at EXAMPLE.LOCAL". If I'm not mistaken, this means that when you create files, NFS communicates the owner as "admin at example.local". Your idmappers are probably trying to translate this to a local account called "admin" whenever evaluating permissions. If nfs-client and nfs-server can both "getent passwd admin" successfully, then you're probably OK. Otherwise, sssd may need some work... But that shouldn't interfere with just mounting the share. (I just checked on my little test setup.) My little test setup doesn't involve IPA, it's just a couple of fedora20 VMs with mit krb5 and an nfs server. I did google this: http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html Note the part about the campus windows AD admins setting the NO_AUTH_DATA_REQUIRED flag for the machine accounts in AD. Is preauth turned off for your nfs/nfs-client.... and nfs/nfs-server... principals? I fear I'm ignorant of how this is done in IPA. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From sbose at redhat.com Mon Feb 17 08:34:33 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 17 Feb 2014 09:34:33 +0100 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: References: Message-ID: <20140217083433.GI15419@localhost.localdomain> On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote: > I have seen threads where opened on trust issues: > "AD - Freeipa trust confusion" > "Cross domain trust" > "Cannot loging via SSH with AD user TO IPA Domain" - which I opened. > > It looks like after creation of trust, TGT ticket can be issued from AD, > but "su" and "ssh" do not allow a log in with AD user. > I'm not sure if a conclusion has been reached on this subject. > > I gave it a try again and attempted to create a trust with IPA as a DNS > subdomain of AD. > I followed : > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html > > AD domain: ADEXAMPLE.COM > IPA subdoamin: LINUX.ADEXAMPLE.COM > > When i finished the necessary steps i attempted to retrieve a TGT from AD > (while logged in to IPA server): > > [root at ipaserver1 sbin]# kinit Administrator at ADEXAMPLE.COM > Password for Administrator at ADEXAMPLE.COM: > [root at ipaserver1 sbin]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: Administrator at ADEXAMPLE.COM > > Valid starting Expires Service principal > 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/ADEXAMPLE.COM at ADEXAMPLE.COM > renew until 02/15/14 07:50:21 > > But logging in by "ssh" and "su" ended in failure: > > login as: Administrator at ADEXAMPLE.COM > Administrator at ADDC.COM@192.168.227.201's password: > Access denied > > After reading > http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini > did the following on the AD server: > > Administrative Tools -> Active Directory Domains and Trust -> > adexample.com(right click) -> Properties -> Trust -> Domain Trusted by > this domain > (outgoing trust) -> Properties -> General -> Validate > > *After doing this i was able to login via "ssh" and "su" with > "Administrator" **user :* > > login as: Administrator at ADEXAMPLE.COM > Administrator at ADEXAMPLE.COM@192.168.227.201's password: > Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 > Could not chdir to home directory /home/adexample.com/administrator: No > such file or directory > /usr/bin/xauth: error in locking authority file /home/ > adexample.com/administrator/.Xauthority > -sh-4.1$ > > *But still not able to login with other AD accounts:* > > [root at ipaserver1 sbin]# su Genadi at ADEXAMPLE.COM > su: user Genadi at ADEXAMPLE.COM does not exist > > After reading the other threads, ill try and provide as much information as > i can: > > *wbinfo -u does not return values.* > [root at ipaserver1 sbin]# wbinfo -u > [root at ipaserver1 sbin]# > > *wbinfo -u output:* > [root at ipaserver1 sbin]# wbinfo -g > admins > editors > default smb group > ad_users > > *wbinfo --online-status shows ADEXAMPLE is offline* > [root at ipaserver1 ~]# wbinfo --online-status > BUILTIN : online > LINUX : online > ADEXAMPLE : offline > > *getent for Administrator does return value.* > [root at ipaserver1 sbin]# getent passwd Administrator at ADEXAMPLE.COM > administrator at adexample.com:*:699000500:699000500::/home/ > adexample.com/administrator: > > *getent for other AD users does not return value.* > [root at ipaserver1 sbin]# getent passwd Genadi at ADEXAMPLE.COM > [root at ipaserver1 sbin]# > > > *System info/configurations:* > > [root at ipaserver1 ~]# cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) > > [root at ipaserver1 sbin]# rpm -qa | grep ipa > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > libipa_hbac-python-1.9.2-129.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-server-trust-ad-3.0.0-37.el6.x86_64 > libipa_hbac-1.9.2-129.el6.x86_64 > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-server-3.0.0-37.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > > [root at ipaserver1 ~]# rpm -qa | grep sssd > sssd-1.9.2-129.el6.x86_64 > sssd-client-1.9.2-129.el6.x86_64 > > [root at ipaserver1 sbin]# rpm -qa | grep samb > samba4-common-4.0.0-60.el6_5.rc4.x86_64 > samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 > samba4-libs-4.0.0-60.el6_5.rc4.x86_64 > samba4-python-4.0.0-60.el6_5.rc4.x86_64 > samba4-4.0.0-60.el6_5.rc4.x86_64 > samba4-client-4.0.0-60.el6_5.rc4.x86_64 > samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 Thank you very much for the detailed report. Looks like you are hit by the 'NT_STATUS_INVALID_PARAMETER_MIX' issue (see log.wb-ADEXAMPLE). We are currently investigating this issue. I you would like to help it would be nice if you can try to downgrade the samba4 packages to the -58 release and see if this works any better for you. Currently I'll try tor reproduce this issue locally and will give you an update as soon as I find anything which might help to get around this issue. bye, Sumit > > *SSSD* > > [root at ipaserver1 ~]# cat /etc/sssd/sssd.conf > [domain/linux.adexample.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = linux.adexample.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipaserver1.linux.adexample.com > chpass_provider = ipa > ipa_server = ipaserver1.linux.adexample.com > ldap_tls_cacert = /etc/ipa/ca.crt > subdomains_provider = ipa > debug_level = 6 > [sssd] > services = nss, pam, ssh, pac > config_file_version = 2 > > domains = linux.adexample.com > debug_level = 6 > [nss] > debug_level = 6 > [pam] > debug_level = 6 > [sudo] > debug_level = 6 > [autofs] > debug_level = 6 > [ssh] > debug_level = 6 > [pac] > debug_level = 6 > > *KRB5* > > [root at ipaserver1 ~]# cat /etc/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 = LINUX.ADEXAMPLE.COM > dns_lookup_realm = false > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > LINUX.ADEXAMPLE.COM = { > kdc = ipaserver1.linux.adexample.com:88 > master_kdc = ipaserver1.linux.adexample.com:88 > admin_server = ipaserver1.linux.adexample.com:749 > default_domain = linux.adexample.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ > ADEXAMPLE.COM/@adexample.com/ > auth_to_local = DEFAULT > } > > [domain_realm] > .linux.adexample.com = LINUX.ADEXAMPLE.COM > linux.adexample.com = LINUX.ADEXAMPLE.COM > > [dbmodules] > LINUX.ADEXAMPLE.COM = { > db_library = ipadb.so > } > > I have increased the debug level of the IPA components. > Here are the logs (*krb5_child.log, **ldap_child.log, **log.smbd, > **log.wb-ADEXAMPLE, > **log.wb-LINUX, **log.winbindd, **log.winbindd-dc-connect, > log.winbindd-idmap*, *sssd.log*, *sssd_linux.adexample.com.log*,*sssd_nss.log, > **sssd_pac.log*, *sssd_pam.log, * > > > > *sssd_ssh.log, /var/log/secure):https://gist.github.com/anonymous/9006532 > * > Any insights on why only Administrator is recognized by the Trust? And why > extra step on AD was needed? > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From pbrezina at redhat.com Mon Feb 17 08:46:53 2014 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Mon, 17 Feb 2014 09:46:53 +0100 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: References: Message-ID: <5301CC7D.6050903@redhat.com> On 02/16/2014 01:19 AM, Steve Dainard wrote: > Just experienced the same issue on Fedora 20: > > [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on fed20. This > incident will be reported. > [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld > [sudo] password for sdainard-admin at miovision.corp: > [sdainard-admin at miovision.corp@fed20 ~]$ > > Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). > > /var/log/messages: > Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall > daemon... > Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon. > > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------------------------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. > If you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard > wrote: > > On a Ubuntu 13.10 client after configuring sssd to provide sudo > service I left the client idle for a few hours. On returning, I > unlocked the screensaver and did the following: > > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.corp/sdainard-admin# > > I haven't experienced this on a Fedora 20 or EL client so I'm > guessing this is something specific to Ubuntu. > > I've attached the client sssd log if anyone can point me in the > right direction. > > Thanks, > > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------------------------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, > Kitchener, ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or > confidential. If you are not the intended recipient, please delete > the e-mail and any attachments and notify us immediately. Hi, provided logs did not reveal anything bad. Can you also attach sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and sudo version do you run? Is this always reproducible or it happens only sporadically? Thanks. From jhrozek at redhat.com Mon Feb 17 14:03:00 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 17 Feb 2014 15:03:00 +0100 Subject: [Freeipa-users] authentication against compat In-Reply-To: <20140214073633.GA27001@redhat.com> References: <52FB8577.3010601@martos.bme.hu> <52FBBDE3.4090102@redhat.com> <52FBEEE2.5060500@martos.bme.hu> <52FBFC41.4050200@redhat.com> <4602C745E3CF40A0AEED175DF09D340E@willsheldon.com> <20140213084637.GF1342@hendrix.redhat.com> <20140213221543.GZ1342@hendrix.redhat.com> <20140214073633.GA27001@redhat.com> Message-ID: <20140217140300.GE7979@hendrix.brq.redhat.com> On Fri, Feb 14, 2014 at 09:36:33AM +0200, Alexander Bokovoy wrote: > On Thu, 13 Feb 2014, Steve Dainard wrote: > >I don't think this is an issue of bugs or documentation, more of design. > >Perhaps there's someplace other than a users list this belongs in but: > > > >If IPA is a centrally managed identity and access control system, should > >these configurations not be passed to clients, rather than every client > >needing configuration changes post join? Obviously I can automate config > >changes, but why would I want to? I don't think sudoers priv is a fringe > >case, its pretty much THE case for access/admin control. I cringe to > >compare to a Windows domain, but I don't have to manually tell a domain > >client that it should respect the rules I set on a domain controller, I > >joined it to the domain for this reason. > When majority of expected features are already implemented, it is easy > to fall into assumption that everything has to be complete from start. > That's understandable but we are dealing with a living and evolving > project where a feature addition often means integrating across multiple > actual free software projects, all with their own priorities and > schedules, step by step, or things will never happen. > > SUDO integration is not an exception here. First we needed to expand > SUDO's support for external plugins. When SUDO data was placed in LDAP, > it appeared that existing schema isn't really optimal, so FreeIPA schema > was designed better (but incompatible with existing one from SUDO LDAP), > but required a compatibility part to work with existing SUDO LDAP > plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO > LDAP schema as it gave SSSD wider coverage of SUDO support. Now we > implemented support for native FreeIPA schema. The next step is to > integrate configuration of it in ipa-client-install so that clients will > get set up properly if there are SUDO rules configured on the server or > ipa-client-install was actually given a bless from the admin (via CLI > option or answering a question). > > It takes time and effort. Unsurprisingly, this is a relatively minor > feature in the grand picture because we have dozens of such features all > asking for attention and time, and our development teams are not > expanding infinitely regardless how we all wished. :) > > Any help is welcome! By the way the native sudo backend is being worked on actively by an external contributor in the form of a thesis. We expect to have it implemented by May. From jhrozek at redhat.com Mon Feb 17 14:08:10 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 17 Feb 2014 15:08:10 +0100 Subject: [Freeipa-users] Setting up sudo In-Reply-To: <52FD559D.4090603@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> <6FB698E172A95F49BE009B36D56F53E2273242@EXCHMB1-ELS.BWINC.local> <52FD559D.4090603@redhat.com> Message-ID: <20140217140810.GG7979@hendrix.brq.redhat.com> On Thu, Feb 13, 2014 at 06:30:37PM -0500, Dmitri Pal wrote: > On 02/13/2014 06:23 PM, Todd Maugh wrote: > >and If I am configuring the sud-ldap.conf > > > > > >what should it look like does any one have an example? > > > > You have two options. Sudo can be integrated with SSSD or not. > If you want SUDO to be integrated then this should help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Also man sssd-sudo should have some examples. From andrew.holway at gmail.com Mon Feb 17 14:25:57 2014 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 17 Feb 2014 14:25:57 +0000 Subject: [Freeipa-users] Setting up sudo In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2273214@EXCHMB1-ELS.BWINC.local> Message-ID: It actually took me a long time to find this information. It is poorly documented but this mailing list post works. :) https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html On 13 February 2014 23:17, Todd Maugh wrote: > the documentation is kinda vague on some parts > > from the documentation: > > Because the sudo information is not available anonymously over LDAP by > default, Identity Management defines a default sudo user, > uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo > configuration file, /etc/sud-ldap.conf. > > so is this user supposed to already pre defined. or do I need to create the > user, and then modify them > > thanks > > -Todd > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Mon Feb 17 14:40:26 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 17 Feb 2014 15:40:26 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52FE41D3.4070308@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> Message-ID: <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> >>>> It would seem like we're still encountering some issues. The date has now passed for when >>>> the old certificate expired, and the "ipa" cli command no longer works. The webui is still >>>> working just fine. >>>> >>>> These are the errors I receive. >>>> >>>> >>>> >>>> $ ipa user-find >>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by >>>> the user.) ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by >>>> the user.) ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>> ((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://serveripa03.example.com/ipa/xml, >>>> https://serveripa01.example.com/ipa/xml, >>>> https://serveripa02.example.com/ipa/xml >>>> >>>> >>> >>> This seems more like a client-side issue. Can you confirm that >>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>> contains the CA? >>> >>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>> >> >> >> The CA seem to be available. I ran the command on ipa01. See below for the output. >> >> >> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >> command from a remote machine. >> >> >> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 1 (0x1) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >> Validity: >> Not Before: Thu Jan 19 19:44:21 2012 >> Not After : Sun Jan 19 19:44:21 2020 >> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> > > Perhaps we can brute force things to see what is going on. We can pass > some extra options to the ipa tool to get ultra verbose output: > > $ ipa -vv -e debug=True user-show admin > > > The thing to do is to check the server that it is communicating with and > check /var/log/httpd/errors to see if there is an equivalent error logged there. > I've sent you the full output in private. Could this be the reason for why it fails? ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Regards, Siggi From mkosek at redhat.com Mon Feb 17 15:00:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Feb 2014 16:00:50 +0100 Subject: [Freeipa-users] IPA Replica cannot add user [SOLVED] In-Reply-To: <52FE10E1.7070205@redhat.com> References: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> <52FE10E1.7070205@redhat.com> Message-ID: <53022422.2010901@redhat.com> On 02/14/2014 01:49 PM, Martin Kosek wrote: > Ok, this part seems ok then. I would then focus directly on DNA operation itself. > > DNA plugin says: > > [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_request_range: Error sending > range extension extended operation request to server ipa01.example.com:389 > [error 53] > [13/Feb/2014:15:32:02 -0200] dna-plugin - dna_pre_op: no more values available!! > > Error 53 should be Unwilling to perform. Are there any errors on master dirsrv > errors log? > > Is any free number available on the master server? > > [master] $ ldapsearch -h `hostname` -D "cn=Directory Manager" -x -W -b > 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' > dnaNextValue dnaMaxValue > > Martin > > On 02/14/2014 12:36 PM, Bruno Henrique Barbosa wrote: >> Hi Martin, thanks for the help. >> >> >> Yes, I already did that test. Created a user on ipa01 (master), then he appeared on ipa02 (replica), in the replica, I modified his email address, it appeared back on master. Still, I cannot create a brand new user (or POSIX group) on ipa02. >> >> >> >> [root at ipa01 ~]# ipactl status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> CA Service: RUNNING >> >> >> >> [root at ipa02 ~]# ipactl status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> >> >> >> >> Interesting on replica's /var/log/krb5kdc.log: >> >> >> >> [root at ipa02 ~]# cat /var/log/krb5kdc.log | grep "Feb 13 15:31" >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): setting up network... >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 6: udp 0.0.0.0.88 (pktinfo) >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): skipping unrecognized local address family 17 >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 8: tcp 0.0.0.0.88 >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): listening on fd 7: tcp ::.88 >> Feb 13 15:31:13 ipa02 krb5kdc[1524](info): set up 3 sockets >> Feb 13 15:31:13 ipa02 krb5kdc[1525](info): creating 4 worker processes >> Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 7 >> Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 8 >> Feb 13 15:31:13 ipa02 krb5kdc[1525](info): closing down fd 6 >> Feb 13 15:31:13 ipa02 krb5kdc[1535](info): commencing operation >> Feb 13 15:31:13 ipa02 krb5kdc[1533](info): commencing operation >> Feb 13 15:31:13 ipa02 krb5kdc[1536](info): commencing operation >> Feb 13 15:31:13 ipa02 krb5kdc[1534](info): commencing operation >> Feb 13 15:31:14 ipa02 krb5kdc[1534](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required >> Feb 13 15:31:14 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> >> >> Feb 13 15:31:14 ipa02 krb5kdc[1536](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312674, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for ldap/ipa01.example.com at EXAMPLE.COM >> >> >> Feb 13 15:31:28 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required >> Feb 13 15:31:28 ipa02 krb5kdc[1535](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> Feb 13 15:31:28 ipa02 krb5kdc[1535](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392312688, etypes {rep=18 tkt=18 ses=18}, user01 at EXAMPLE.COM for ldap/ipa02.example.com at EXAMPLE.COM >> >> >> >> >> Running kinit -kt on replica, returns nothing on prompt, but populates /var/log/krb5kdc.log with: >> >> >> >> >> Feb 14 09:34:05 ipa02 krb5kdc[1536](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: NEEDED_PREAUTH: ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required >> Feb 14 09:34:05 ipa02 krb5kdc[1533](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.2: ISSUE: authtime 1392377645, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> >> >> >> >> DNS is OK, resolving FQDN of both master and replica forward and reverse. >> >> >> >> Bruno Henrique Barbosa >> >> Jr. Sys Admin >> IT Department >> Santos City Hall >> ----- Mensagem original ----- >> >> De: "Martin Kosek" >> Para: "Bruno Henrique Barbosa" , freeipa-users at redhat.com >> Enviadas: Sexta-feira, 14 de Fevereiro de 2014 5:51:49 >> Assunto: Re: [Freeipa-users] IPA Replica cannot add user >> >> On 02/13/2014 06:55 PM, Bruno Henrique Barbosa wrote: >>> >>> >>> >>> Hi everyone, >>> >>> >>> I've installed my IPA environment as it follows: >>> >>> >>> ipa01.example.com - master install >>> ipa02.example.com - replica install, as the guide says, with ipa-replica-prepare on ipa01 and ipa-replica-install using gpg key generated. >>> >>> >>> All good, environment is fine, can access both UI, but the underlying problem is: I can edit and remove users from IPA using instance ipa02 (replica), but I CANNOT add users from that instance. In the UI, error returned is: >>> >>> >>> IPA Error 4203 >>> Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >>> >>> >>> >>> >>> Via command-line, debug-enabled: >>> >>> >>> root at ipa02's password: >>> Last login: Thu Feb 13 15:36:34 2014 >>> [root at ipa02 ~]# kinit admin >>> Password for admin at EXAMPLE.COM: >>> [root at ipa02 ~]# ipa-replica-manage list >>> ipa01.example.com: master >>> ipa02.example.com: master >>> [root at ipa02 ~]# klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: admin at EXAMPLE.COM >>> >>> >>> Valid starting Expires Service principal >>> 02/13/14 15:37:48 02/14/14 15:37:29 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>> 02/13/14 15:38:03 02/14/14 15:37:29 ldap/ipa02.example.com at EXAMPLE.COM >>> [root at ipa02 ~]# ipa -d user-add usertest >>> ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' >>> ipa: DEBUG: args=klist -V >>> ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 >>> >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' >>> ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' >>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=keyctl_search: Required key not available >>> >>> >>> ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at EXAMPLE.COM' >>> ipa: INFO: trying https://ipa02.example.com/ipa/xml >>> ipa: DEBUG: NSSConnection init ipa02.example.com >>> ipa: DEBUG: Connecting: 192.168.0.2:0 >>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 14 (0xe) >>> Signature Algorithm: >>> Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Issuer: CN=Certificate Authority,O=EXAMPLE.COM >>> Validity: >>> Not Before: Qua Fev 12 19:42:11 2014 UTC >>> Not After: S?b Fev 13 19:42:11 2016 UTC >>> Subject: CN=ipa02.example.com,O=EXAMPLE.COM >>> Subject Public Key Info: >>> Public Key Algorithm: >>> Algorithm: PKCS #1 RSA Encryption >>> RSA Public Key: >>> Modulus: >>> 93:ce:2f:b4:3c:61:bd:ec:42:a2:cd:b2:44:1a:ad:14: >>> f0:50:89:d7:cc:5d:cf:96:db:0e:f5:39:4c:8d:26:b5: >>> 47:9c:e6:77:86:1b:7a:ec:22:64:a2:f8:dd:67:fa:0f: >>> 49:16:e9:9a:ca:d8:0e:d9:37:d6:0c:92:9c:a4:1f:b5: >>> 43:e4:80:0f:80:de:a8:f4:4b:8f:97:db:24:08:9b:24: >>> e7:e8:7a:a7:f8:61:0d:c1:d0:6e:89:94:4b:9d:f3:65: >>> 6a:a8:81:21:fc:7e:e8:72:5d:bb:0f:3e:bb:0c:ce:da: >>> 58:34:b4:64:ed:ac:ab:17:2b:c6:75:87:6d:8d:8e:3f: >>> 3f:56:82:f8:0c:f7:d7:a3:dc:73:b7:60:88:6f:f4:76: >>> db:d6:81:44:c7:04:7c:22:90:c6:f7:bc:0a:34:2a:28: >>> 2a:15:46:9e:06:da:bd:42:10:c0:d3:c4:5e:81:88:6d: >>> 6d:75:ad:3e:f0:a2:88:2e:3d:23:ce:19:a7:71:3c:0a: >>> c0:fa:bd:54:c5:c2:d5:f1:46:b1:74:80:65:31:dc:bb: >>> d5:01:86:de:f5:38:c6:cd:ad:2d:3a:32:17:4f:c7:d4: >>> 2a:44:82:69:4a:ad:d2:1a:59:cb:bb:25:3b:86:50:fa: >>> c7:8c:ab:0f:bf:1f:82:39:c0:ba:7b:45:6e:b6:1f:fd >>> Exponent: >>> 65537 (0x10001) >>> Signed Extensions: (5) >>> Name: Certificate Authority Key Identifier >>> Critical: False >>> Key ID: >>> 7f:77:f3:aa:bc:9a:8a:97:0f:29:2c:b6:a4:ff:81:ea: >>> c3:9c:48:63 >>> Serial Number: None >>> General Names: [0 total] >>> >>> >>> Name: Authority Information Access >>> Critical: False >>> >>> >>> Name: Certificate Key Usage >>> Critical: True >>> Usages: >>> Digital Signature >>> Non-Repudiation >>> Key Encipherment >>> Data Encipherment >>> >>> >>> Name: Extended Key Usage >>> Critical: False >>> Usages: >>> TLS Web Server Authentication Certificate >>> TLS Web Client Authentication Certificate >>> >>> >>> Name: Certificate Subject Key ID >>> Critical: False >>> Data: >>> ba:bd:55:29:33:53:0c:6b:fb:54:2f:ce:ce:40:ce:4c: >>> 55:7c:07:ec >>> >>> >>> Signature: >>> Signature Algorithm: >>> Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Signature: >>> b5:b0:34:b0:4c:e0:97:42:55:2e:44:34:d0:b9:12:c1: >>> 1d:60:57:a4:ae:e7:2e:22:74:a9:fd:64:99:2c:54:7d: >>> f0:b9:32:8e:bd:d5:71:c5:23:14:a1:82:3f:63:c1:bf: >>> 7b:e3:e1:3c:32:95:ca:48:22:eb:56:98:2b:71:90:34: >>> 9c:24:58:02:15:e2:ed:a8:81:11:bd:a9:1a:80:7d:a1: >>> 23:d6:33:78:9b:1a:b6:42:43:49:7e:07:02:a4:7a:1b: >>> f5:8c:78:a2:23:27:66:be:5f:30:43:a0:46:9b:0e:8d: >>> 76:9a:b0:6c:e6:ba:54:d2:9d:7a:24:ae:c9:7f:ee:bf: >>> 5b:6b:b0:c2:3a:ac:d0:9d:cf:d6:36:ec:2b:6d:e9:c2: >>> df:ac:27:d6:63:0a:c0:0f:1b:bc:93:8f:0f:4c:62:ca: >>> f9:c1:10:94:77:5d:b8:ad:f5:b6:18:1c:26:bc:3d:70: >>> 30:20:a3:7e:14:e3:a1:84:d4:9f:f8:73:4c:6d:59:a6: >>> 8d:2b:e3:3f:b5:84:42:62:b9:90:23:dc:24:df:ed:42: >>> bc:ab:f4:a4:5e:9f:ed:7f:e3:f2:e5:f4:07:81:ac:7c: >>> c4:5d:34:6b:69:7b:6f:29:20:30:95:ef:d3:45:ad:83: >>> 51:fb:72:cb:a4:eb:85:f3:f6:0d:2d:31:d8:8b:72:54 >>> Fingerprint (MD5): >>> 4e:06:54:a8:e4:62:8e:65:a1:7f:3c:31:01:4b:06:bf >>> Fingerprint (SHA1): >>> a2:43:5f:65:c0:61:13:cf:2c:9c:9d:32:72:d6:cc:78: >>> 66:6e:f7:77 >>> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >>> ipa: DEBUG: cert valid True for "CN=ipa02.example.com,O=EXAMPLE.COM" >>> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >>> ipa: DEBUG: received Set-Cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' >>> ipa: DEBUG: storing cookie 'ipa_session=eb4b207ba589878a328ee100b9ab16ae; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:58:46 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=keyctl_search: Required key not available >>> >>> >>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=keyctl_search: Required key not available >>> >>> >>> ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at EXAMPLE.COM @s >>> ipa: DEBUG: stdout=227287872 >>> >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Created connection context.xmlclient >>> First name: usertest >>> Last name: testname >>> ipa: DEBUG: raw: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >>> ipa: DEBUG: user_add(u'usertest', givenname=u'usertest', sn=u'testname', cn=u'usertest testname', displayname=u'usertest testname', initials=u'ut', gecos=u'usertest testname', krbprincipalname=u'usertest at EXAMPLE.COM', random=False, uidnumber=999, gidnumber=999, noprivate=False, all=False, raw=False, version=u'2.49', no_members=False) >>> ipa: INFO: Forwarding 'user_add' to server u'https://ipa02.example.com/ipa/xml' >>> ipa: DEBUG: NSSConnection init ipa02.example.com >>> ipa: DEBUG: Connecting: 192.168.0.2:0 >>> ipa: DEBUG: handshake complete, peer = 192.168.0.2:443 >>> ipa: DEBUG: received Set-Cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' >>> ipa: DEBUG: storing cookie 'ipa_session=d5dcde16a47612ec6debfc7ed42b5efb; Domain=ipa02.example.com; Path=/ipa; Expires=Thu, 13 Feb 2014 17:59:04 GMT; Secure; HttpOnly' for principal admin at EXAMPLE.COM >>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >>> ipa: DEBUG: stdout=227287872 >>> >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at EXAMPLE.COM >>> ipa: DEBUG: stdout=227287872 >>> >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: args=keyctl pupdate 227287872 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Caught fault 4203 from server https://ipa02.example.com/ipa/xml: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. >>> >>> >>> >>> >>> Under the labs I did on IPA, I could resolve that by booting the replica server, but this time I couldn't solve. Looking for assistance, please! >>> >>> >>> Thank you for any help you can provide in this situation! >>> >>> >>> Bruno Henrique Barbosa >>> Jr. Sys Admin >>> IT Department >>> Santos City Hall >> >> Hello Bruno, >> >> I saw the logs you sent to Dmitri. It seems to me that the replication link is >> broken, thus replica DNA plugin cannot acquire DNA ranges from master, thus it >> has no available range, thus adding users fails as DS cannot allocate UID and GID. >> >> I think your replication will be broken as well, did you verify that users you >> delete/modify on replica are also deleted/modified on master? >> >> I think the root cause is this log: >> >> [13/Feb/2014:15:31:11 -0200] set_krb5_creds - Could not get initial credentials >> for principal [ldap/ipa02.example.com at EXAMPLE.COM] in keytab >> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested >> realm) >> >> Is your KDC running? >> >> [replica] # ipactl status >> >> You can also try to kinit manually to debug: >> >> [replica] # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa02.example.com at EXAMPLE.COM >> >> If it does not succeed, neither it'd succeed for the DS. >> >> I would also recommend checking that DNS is sane. You can find some pointers here: >> http://www.freeipa.org/page/Troubleshooting#DNS_Issues >> >> HTH, >> Martin Bruno sent me the logs privately, let me just share the solution of this case with the list. The problem here was that master had only 1000 numbers allocated (chosen during IPA installation). Therefore, it had less than 1000 numbers free. When the replica asked for some free numbers from it, it refused to give any as it would lower it's pool of free numbers below 500 (dnaThreshold setting). Bruno was able to fix the issue with this command run on master: $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: dnaMaxValue dnaMaxValue: 5000 Martin From rcritten at redhat.com Mon Feb 17 15:25:59 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 10:25:59 -0500 Subject: [Freeipa-users] IPA Replica cannot add user [SOLVED] In-Reply-To: <53022422.2010901@redhat.com> References: <766e2238-b7f7-4690-a2c1-d30f412fab1d@prod190.prodesan.com.br> <52FE10E1.7070205@redhat.com> <53022422.2010901@redhat.com> Message-ID: <53022A07.3010003@redhat.com> Martin Kosek wrote: > On 02/14/2014 01:49 PM, Martin Kosek wrote: > > Bruno sent me the logs privately, let me just share the solution of this case > with the list. The problem here was that master had only 1000 numbers allocated > (chosen during IPA installation). Therefore, it had less than 1000 numbers free. > > When the replica asked for some free numbers from it, it refused to give any as > it would lower it's pool of free numbers below 500 (dnaThreshold setting). > > Bruno was able to fix the issue with this command run on master: > > $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W > dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > changetype: modify > replace: dnaMaxValue > dnaMaxValue: 5000 He should also run idrange-find to see if there is an IPA range listed and adjust it to match the DNA configuration. rob From rcritten at redhat.com Mon Feb 17 15:34:01 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 10:34:01 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> Message-ID: <53022BE9.9090403@redhat.com> Sigbjorn Lie wrote: > > > > On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> >>> >>> >>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>> >>>> Sigbjorn Lie wrote: >>>> >>>> >>>>> >>>>> >>>>> It would seem like we're still encountering some issues. The date has now passed for when >>>>> the old certificate expired, and the "ipa" cli command no longer works. The webui is still >>>>> working just fine. >>>>> >>>>> These are the errors I receive. >>>>> >>>>> >>>>> >>>>> $ ipa user-find >>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by >>>>> the user.) ipa: ERROR: cert validation failed for "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by >>>>> the user.) ipa: ERROR: cert validation failed for "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>> ((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://serveripa03.example.com/ipa/xml, >>>>> https://serveripa01.example.com/ipa/xml, >>>>> https://serveripa02.example.com/ipa/xml >>>>> >>>>> >>>> >>>> This seems more like a client-side issue. Can you confirm that >>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>> contains the CA? >>>> >>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>> >>> >>> >>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>> >>> >>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >>> command from a remote machine. >>> >>> >>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 1 (0x1) >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>> Validity: >>> Not Before: Thu Jan 19 19:44:21 2012 >>> Not After : Sun Jan 19 19:44:21 2020 >>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>> Subject Public Key Info: >>> Public Key Algorithm: PKCS #1 RSA Encryption >>> RSA Public Key: >>> Modulus: >>> >> >> Perhaps we can brute force things to see what is going on. We can pass >> some extra options to the ipa tool to get ultra verbose output: >> >> $ ipa -vv -e debug=True user-show admin >> >> >> The thing to do is to check the server that it is communicating with and >> check /var/log/httpd/errors to see if there is an equivalent error logged there. >> > > I've sent you the full output in private. Could this be the reason for why it fails? > > ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > No, that is normal for a server cert. This pretty clearly looks like an SSL trust issue. Is this happening on every client machine you run the ipa tool or just one? You might want to compare the cert in /etc/pki/nssdb with the one on the Apache server. # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' # certutil -L -d /etc/pki/nssdb -n 'IPA CA' The trust on each should be CT,C,C and can be checked with: # certutil -L -d /etc/pki/nssdb rob From sigbjorn at nixtra.com Mon Feb 17 15:59:43 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 17 Feb 2014 16:59:43 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53022BE9.9090403@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> Message-ID: <57480.213.225.75.97.1392652783.squirrel@www.nixtra.com> On Mon, February 17, 2014 16:34, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> >>>> >>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>>> >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> It would seem like we're still encountering some issues. The date has now passed for >>>>>> when the old certificate expired, and the "ipa" cli command no longer works. The webui >>>>>> is still working just fine. >>>>>> >>>>>> These are the errors I receive. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> $ ipa user-find >>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>>> ((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://serveripa03.example.com/ipa/xml, >>>>>> https://serveripa01.example.com/ipa/xml, >>>>>> https://serveripa02.example.com/ipa/xml >>>>>> >>>>>> >>>>>> >>>>> >>>>> This seems more like a client-side issue. Can you confirm that >>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>>> contains the CA? >>>>> >>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>> >>>> >>>> >>>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>>> >>>> >>>> >>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >>>> command from a remote machine. >>>> >>>> >>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 1 (0x1) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Validity: >>>> Not Before: Thu Jan 19 19:44:21 2012 >>>> Not After : Sun Jan 19 19:44:21 2020 >>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Subject Public Key Info: >>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>> RSA Public Key: >>>> Modulus: >>>> >>>> >>> >>> Perhaps we can brute force things to see what is going on. We can pass >>> some extra options to the ipa tool to get ultra verbose output: >>> >>> $ ipa -vv -e debug=True user-show admin >>> >>> >>> >>> The thing to do is to check the server that it is communicating with and >>> check /var/log/httpd/errors to see if there is an equivalent error logged there. >>> >> >> I've sent you the full output in private. Could this be the reason for why it fails? >> >> >> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >> >> >> Name: Certificate Key Usage >> Critical: True >> Usages: >> Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> > > No, that is normal for a server cert. > > > This pretty clearly looks like an SSL trust issue. Is this happening on > every client machine you run the ipa tool or just one? This is happening on every client I run the ipa tool.It also happens when I run it directly on any of the ipa servers. > > You might want to compare the cert in /etc/pki/nssdb with the one on the > Apache server. > > > # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > > > # certutil -L -d /etc/pki/nssdb -n 'IPA CA' > > > The trust on each should be CT,C,C and can be checked with: > > > # certutil -L -d /etc/pki/nssdb > I see that I have two Server-Certs on ipa01. One of these expired recently, the other is OK. However I do not see any way to delete the old certificate only with certutil, since they both have the same name? on ipa01: $ sudo certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA CT,C,C $ sudo certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI EXAMPLE.COM IPA CA CT,C,C Signing-Cert u,u,u Server-Cert u,u,u Server-Cert u,u,u ipaCert u,u,u on ipa02: $ sudo certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA CT,C,C $ sudo certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI EXAMPLE.COM IPA CA CT,C, Server-Cert u,u,u ipaCert u,u,u $ sudo certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA CT,C,C on ipa03: $ sudo certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u EXAMPLE.COM IPA CA CT,C, ipaCert u,u,u From sigbjorn at nixtra.com Mon Feb 17 16:35:12 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 17 Feb 2014 17:35:12 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53022BE9.9090403@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> Message-ID: <51086.213.225.75.97.1392654912.squirrel@www.nixtra.com> On Mon, February 17, 2014 16:34, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> >>>> >>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>>> >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> It would seem like we're still encountering some issues. The date has now passed for >>>>>> when the old certificate expired, and the "ipa" cli command no longer works. The webui >>>>>> is still working just fine. >>>>>> >>>>>> These are the errors I receive. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> $ ipa user-find >>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>>> ((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://serveripa03.example.com/ipa/xml, >>>>>> https://serveripa01.example.com/ipa/xml, >>>>>> https://serveripa02.example.com/ipa/xml >>>>>> >>>>>> >>>>>> >>>>> >>>>> This seems more like a client-side issue. Can you confirm that >>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>>> contains the CA? >>>>> >>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>> >>>> >>>> >>>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>>> >>>> >>>> >>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >>>> command from a remote machine. >>>> >>>> >>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 1 (0x1) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Validity: >>>> Not Before: Thu Jan 19 19:44:21 2012 >>>> Not After : Sun Jan 19 19:44:21 2020 >>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Subject Public Key Info: >>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>> RSA Public Key: >>>> Modulus: >>>> >>>> >>> >>> Perhaps we can brute force things to see what is going on. We can pass >>> some extra options to the ipa tool to get ultra verbose output: >>> >>> $ ipa -vv -e debug=True user-show admin >>> >>> >>> >>> The thing to do is to check the server that it is communicating with and >>> check /var/log/httpd/errors to see if there is an equivalent error logged there. >>> This error is recorded in the httpd error log. The same error is repeated on all 3 ipa servers. [Mon Feb 17 17:24:16 2014] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate Regards, Siggi From sigbjorn at nixtra.com Mon Feb 17 16:40:04 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 17 Feb 2014 17:40:04 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53022BE9.9090403@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> Message-ID: <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> On Mon, February 17, 2014 16:34, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> >>>> >>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>>> >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> It would seem like we're still encountering some issues. The date has now passed for >>>>>> when the old certificate expired, and the "ipa" cli command no longer works. The webui >>>>>> is still working just fine. >>>>>> >>>>>> These are the errors I receive. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> $ ipa user-find >>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>>> ((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://serveripa03.example.com/ipa/xml, >>>>>> https://serveripa01.example.com/ipa/xml, >>>>>> https://serveripa02.example.com/ipa/xml >>>>>> >>>>>> >>>>>> >>>>> >>>>> This seems more like a client-side issue. Can you confirm that >>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>>> contains the CA? >>>>> >>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>> >>>> >>>> >>>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>>> >>>> >>>> >>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >>>> command from a remote machine. >>>> >>>> >>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 1 (0x1) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Validity: >>>> Not Before: Thu Jan 19 19:44:21 2012 >>>> Not After : Sun Jan 19 19:44:21 2020 >>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>>> Subject Public Key Info: >>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>> RSA Public Key: >>>> Modulus: >>>> >>>> >>> >>> Perhaps we can brute force things to see what is going on. We can pass >>> some extra options to the ipa tool to get ultra verbose output: >>> >>> $ ipa -vv -e debug=True user-show admin >>> >>> >>> >>> The thing to do is to check the server that it is communicating with and >>> check /var/log/httpd/errors to see if there is an equivalent error logged there. >>> >> >> I've sent you the full output in private. Could this be the reason for why it fails? >> >> >> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >> >> >> Name: Certificate Key Usage >> Critical: True >> Usages: >> Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> > > No, that is normal for a server cert. > > > This pretty clearly looks like an SSL trust issue. Is this happening on > every client machine you run the ipa tool or just one? > > You might want to compare the cert in /etc/pki/nssdb with the one on the > Apache server. > > > # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > > > # certutil -L -d /etc/pki/nssdb -n 'IPA CA' > Looks like the same certificate, just with different flags? $ sudo certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > /tmp/ca1 $ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > /tmp/ca2 $ diff /tmp/ca1 /tmp/ca2 90a91,92 > Valid CA > Trusted CA Regards, Siggi From rcritten at redhat.com Mon Feb 17 16:59:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Feb 2014 11:59:04 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> Message-ID: <53023FD8.5060103@redhat.com> Sigbjorn Lie wrote: > > > > On Mon, February 17, 2014 16:34, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >> >>> >>> >>> >>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >>> >>>> Sigbjorn Lie wrote: >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>>>> >>>>> >>>>>> Sigbjorn Lie wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> It would seem like we're still encountering some issues. The date has now passed for >>>>>>> when the old certificate expired, and the "ipa" cli command no longer works. The webui >>>>>>> is still working just fine. >>>>>>> >>>>>>> These are the errors I receive. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ ipa user-find >>>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted >>>>>>> by the user.) ipa: ERROR: cert validation failed for >>>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>>>> ((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://serveripa03.example.com/ipa/xml, >>>>>>> https://serveripa01.example.com/ipa/xml, >>>>>>> https://serveripa02.example.com/ipa/xml >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This seems more like a client-side issue. Can you confirm that >>>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>>>> contains the CA? >>>>>> >>>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>>> >>>>> >>>>> >>>>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>>>> >>>>> >>>>> >>>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa >>>>> command from a remote machine. >>>>> >>>>> >>>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>> Certificate: >>>>> Data: >>>>> Version: 3 (0x2) >>>>> Serial Number: 1 (0x1) >>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>>>> Validity: >>>>> Not Before: Thu Jan 19 19:44:21 2012 >>>>> Not After : Sun Jan 19 19:44:21 2020 >>>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>>>> Subject Public Key Info: >>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>> RSA Public Key: >>>>> Modulus: >>>>> >>>>> >>>> >>>> Perhaps we can brute force things to see what is going on. We can pass >>>> some extra options to the ipa tool to get ultra verbose output: >>>> >>>> $ ipa -vv -e debug=True user-show admin >>>> >>>> >>>> >>>> The thing to do is to check the server that it is communicating with and >>>> check /var/log/httpd/errors to see if there is an equivalent error logged there. >>>> >>> >>> I've sent you the full output in private. Could this be the reason for why it fails? >>> >>> >>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >>> >>> >>> Name: Certificate Key Usage >>> Critical: True >>> Usages: >>> Digital Signature >>> Non-Repudiation >>> Key Encipherment >>> Data Encipherment >>> >>> >> >> No, that is normal for a server cert. >> >> >> This pretty clearly looks like an SSL trust issue. Is this happening on >> every client machine you run the ipa tool or just one? >> >> You might want to compare the cert in /etc/pki/nssdb with the one on the >> Apache server. >> >> >> # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' >> >> >> # certutil -L -d /etc/pki/nssdb -n 'IPA CA' >> > > Looks like the same certificate, just with different flags? > > $ sudo certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > /tmp/ca1 > $ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > /tmp/ca2 > $ diff /tmp/ca1 /tmp/ca2 > 90a91,92 >> Valid CA >> Trusted CA A diff with context would confirm it but I'm assuming this is just the code-signing trust which won't affect anything in this case. You'll notice that some trust is CT,C,C and some just CT,C,. The order is SSL, S/MIME, code signing. On what machine are you trying to use the ipa tool? Is it one of the masters, all of them, enrolled clients? Whatever is going on isn't likely related to the web server Apache database as you get the same error out of each one. The client log you sent confirmed that it tried to contact each master. The SSL error we're getting is that the client doesn't trust the CA that signed the server certificate so this appears to be a problem on the client, which begs the question: all clients or just this one? NSS is smart enough to handle multiple certificates, it should pick the newest one on startup. rob From regpm at mccleary.me.uk Mon Feb 17 19:30:05 2014 From: regpm at mccleary.me.uk (regpm at mccleary.me.uk) Date: Mon, 17 Feb 2014 19:30:05 +0000 Subject: [Freeipa-users] Freeipa-users Digest, Vol 67, Issue 88 In-Reply-To: References: Message-ID: <5302633D.8030501@mccleary.me.uk> Yes, it's the enforced user permissions for NFS shares, versus host-based access controls and matching UIDs/GIDs, that I'm after, especially as I have IPA providing the central user LDAP store. I admit I don't really understand how it all hangs together in terms of requiring a kerberos ticket, but maybe someone can enlighten me or point me to relavant info for IPA. Should a user execute a kinit to get a new ticket before using any services or are their popular approaches to automating this? Both the NFS server and client can getent the admin user so that aspect is fine, but as Bryce states, I'm stuck not even able to mount the share, let alone have any permission issues using it. I have read the link mention by Bryce: http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html At the time I thought the OP had the issue because the keytabs were being created by someone else (Windows AD admins), whereas I'm creating mine with the default options in IPA. It (and other posts) did originally lead me down enabling weak encryption and specifying a specific DES scheme to use and only having this single entry in the keytab for both the host and nfs principals (on both the NFS server and client). Though this made no difference. I've just looked at the ipa man page and can't see how (or if I need) to set either "/crypto ALL" or NO_AUTH_DATA_REQUIRED ipa help service-add Purpose: Add a new IPA new service. Usage: ipa [global-options] service-add PRINCIPAL [options] Positional arguments: PRINCIPAL Service principal Options: -h, --help show this help message and exit --certificate=BYTES Base-64 encoded server certificate --pac-type=['MS-PAC', 'PAD', 'NONE'] Override default list of supported PAC types. Use 'NONE' to disable PAC support for this service --setattr=STR Set an attribute to a name/value pair. Format is attr=value. For multi-valued attributes, the command replaces the values already present. --addattr=STR Add an attribute/value pair. Format is attr=value. The attribute must be part of the schema. --force force principal name even if not in DNS --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. Likewise, I looked for attributes against a test user and could find nothing about setting preauth or the NO_AUTH_DATA_REQUIRED flag above. Maybe I'm looking in the wrong place/way? ipa user-show --all User login: joebloggsuser dn: uid=joebloggsuser,cn=users,cn=accounts,dc=example,dc=local User login: joebloggsuser First name: Joe Last name: Bloggs Full name: Joe Bloggs Display name: Joe Bloggs Initials: JB Home directory: /home/joebloggsuser GECOS field: Joe Bloggs Login shell: /bin/bash Kerberos principal: joebloggsuser at EXAMPLE.LOCAL Email address: joebloggs at example.local UID: 94600001 GID: 94600001 Account disabled: False SSH public key: ssh-rsa joebloggsuser at example.local Password: True Member of groups: ipausers, super Indirect Member of group: admins, editors, trust admins, exampleusers, advocacy, managers Kerberos keys available: True SSH public key fingerprint: joebloggsuser at example.local (ssh-rsa) ipauniqueid: 511c7d14-91d0-11e3-b10e-001a4ab13d9f krbextradata: BBBoyf9Sa2FkzxluZEBCRFMuTE9EQUvA krblastfailedauth: 20140215200740Z krblastpwdchange: 20140215200912Z krblastsuccessfulauth: 20140217003353Z krbloginfailedcount: 0 krbpasswordexpiration: 20150215200912Z krbpwdpolicyreference: cn=super,cn=EXAMPLE.LOCAL,cn=kerberos,dc=example,dc=local krbticketflags: 128 mepmanagedentry: cn=joebloggsuser,cn=groups,cn=accounts,dc=example,dc=local objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry Any ideas how I can move this forward, as kerberized NFS would definitely be preferable and I thought this would be easy with IPA? Thanks, Paul On 17/02/2014 14:26, freeipa-users-request at redhat.com wrote: > 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: Kerberized NFS Mount Issues (Nordgren, Bryce L -FS) > 2. Re: Issues creating trust with AD. (Sumit Bose) > 3. Re: Sudo denied on first attempt, allowed on second attempt > (Pavel B?ezina) > 4. Re: authentication against compat (Jakub Hrozek) > 5. Re: Setting up sudo (Jakub Hrozek) > 6. Re: Setting up sudo (Andrew Holway) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Feb 2014 23:10:58 +0000 > From: "Nordgren, Bryce L -FS" > To: "regpm at mccleary.me.uk" , > "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Kerberized NFS Mount Issues > Message-ID: > <82E7C9A01FD0764CACDD35D10F5DFB6E68E086 at 001FSN2MPN1-045.001f.mgd2.msft.net> > > Content-Type: text/plain; charset="iso-8859-1" > > >> You raise a good point regarding kinit - do I have to be kinit'ed in as anybody >> before trying to mount the share? I thought as the host and service principals >> are in the /etc/krb5.keytab I didn't need to specifically authenticate against >> the IPA server? - I might be showing a fundamental lack of knowledge on how >> this all works, so would be good if someone could confirm or clarify this. > The big feature of NFSv4 w/krb security is per-user authentication/authorization. NFSv4 with sec=sys (and all NFS <4) use host-based authorization. I'm pretty sure you should be able to mount the NFS export without 'kinit'ing, but I'm also pretty sure it should look empty (or even give you "permission denied" until you kinit to someone authorized to access it. > > I see you "kinit"ed to "admin at EXAMPLE.LOCAL". If I'm not mistaken, this means that when you create files, NFS communicates the owner as "admin at example.local". Your idmappers are probably trying to translate this to a local account called "admin" whenever evaluating permissions. If nfs-client and nfs-server can both "getent passwd admin" successfully, then you're probably OK. Otherwise, sssd may need some work... > > But that shouldn't interfere with just mounting the share. (I just checked on my little test setup.) My little test setup doesn't involve IPA, it's just a couple of fedora20 VMs with mit krb5 and an nfs server. I did google this: http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html > > Note the part about the campus windows AD admins setting the NO_AUTH_DATA_REQUIRED flag for the machine accounts in AD. Is preauth turned off for your nfs/nfs-client.... and nfs/nfs-server... principals? I fear I'm ignorant of how this is done in IPA. > > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > > > > > ------------------------------ > > Message: 2 > Date: Mon, 17 Feb 2014 09:34:33 +0100 > From: Sumit Bose > To: Genadi Postrilko > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Issues creating trust with AD. > Message-ID: <20140217083433.GI15419 at localhost.localdomain> > Content-Type: text/plain; charset=us-ascii > > On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote: >> I have seen threads where opened on trust issues: >> "AD - Freeipa trust confusion" >> "Cross domain trust" >> "Cannot loging via SSH with AD user TO IPA Domain" - which I opened. >> >> It looks like after creation of trust, TGT ticket can be issued from AD, >> but "su" and "ssh" do not allow a log in with AD user. >> I'm not sure if a conclusion has been reached on this subject. >> >> I gave it a try again and attempted to create a trust with IPA as a DNS >> subdomain of AD. >> I followed : >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html >> >> AD domain: ADEXAMPLE.COM >> IPA subdoamin: LINUX.ADEXAMPLE.COM >> >> When i finished the necessary steps i attempted to retrieve a TGT from AD >> (while logged in to IPA server): >> >> [root at ipaserver1 sbin]# kinit Administrator at ADEXAMPLE.COM >> Password for Administrator at ADEXAMPLE.COM: >> [root at ipaserver1 sbin]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: Administrator at ADEXAMPLE.COM >> >> Valid starting Expires Service principal >> 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/ADEXAMPLE.COM at ADEXAMPLE.COM >> renew until 02/15/14 07:50:21 >> >> But logging in by "ssh" and "su" ended in failure: >> >> login as: Administrator at ADEXAMPLE.COM >> Administrator at ADDC.COM@192.168.227.201's password: >> Access denied >> >> After reading >> http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini >> did the following on the AD server: >> >> Administrative Tools -> Active Directory Domains and Trust -> >> adexample.com(right click) -> Properties -> Trust -> Domain Trusted by >> this domain >> (outgoing trust) -> Properties -> General -> Validate >> >> *After doing this i was able to login via "ssh" and "su" with >> "Administrator" **user :* >> >> login as: Administrator at ADEXAMPLE.COM >> Administrator at ADEXAMPLE.COM@192.168.227.201's password: >> Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 >> Could not chdir to home directory /home/adexample.com/administrator: No >> such file or directory >> /usr/bin/xauth: error in locking authority file /home/ >> adexample.com/administrator/.Xauthority >> -sh-4.1$ >> >> *But still not able to login with other AD accounts:* >> >> [root at ipaserver1 sbin]# su Genadi at ADEXAMPLE.COM >> su: user Genadi at ADEXAMPLE.COM does not exist >> >> After reading the other threads, ill try and provide as much information as >> i can: >> >> *wbinfo -u does not return values.* >> [root at ipaserver1 sbin]# wbinfo -u >> [root at ipaserver1 sbin]# >> >> *wbinfo -u output:* >> [root at ipaserver1 sbin]# wbinfo -g >> admins >> editors >> default smb group >> ad_users >> >> *wbinfo --online-status shows ADEXAMPLE is offline* >> [root at ipaserver1 ~]# wbinfo --online-status >> BUILTIN : online >> LINUX : online >> ADEXAMPLE : offline >> >> *getent for Administrator does return value.* >> [root at ipaserver1 sbin]# getent passwd Administrator at ADEXAMPLE.COM >> administrator at adexample.com:*:699000500:699000500::/home/ >> adexample.com/administrator: >> >> *getent for other AD users does not return value.* >> [root at ipaserver1 sbin]# getent passwd Genadi at ADEXAMPLE.COM >> [root at ipaserver1 sbin]# >> >> >> *System info/configurations:* >> >> [root at ipaserver1 ~]# cat /etc/redhat-release >> Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) >> >> [root at ipaserver1 sbin]# rpm -qa | grep ipa >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> libipa_hbac-python-1.9.2-129.el6.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-server-trust-ad-3.0.0-37.el6.x86_64 >> libipa_hbac-1.9.2-129.el6.x86_64 >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-server-3.0.0-37.el6.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> >> [root at ipaserver1 ~]# rpm -qa | grep sssd >> sssd-1.9.2-129.el6.x86_64 >> sssd-client-1.9.2-129.el6.x86_64 >> >> [root at ipaserver1 sbin]# rpm -qa | grep samb >> samba4-common-4.0.0-60.el6_5.rc4.x86_64 >> samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 >> samba4-libs-4.0.0-60.el6_5.rc4.x86_64 >> samba4-python-4.0.0-60.el6_5.rc4.x86_64 >> samba4-4.0.0-60.el6_5.rc4.x86_64 >> samba4-client-4.0.0-60.el6_5.rc4.x86_64 >> samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 > Thank you very much for the detailed report. Looks like you are hit by > the 'NT_STATUS_INVALID_PARAMETER_MIX' issue (see log.wb-ADEXAMPLE). We > are currently investigating this issue. > > I you would like to help it would be nice if you can try to downgrade > the samba4 packages to the -58 release and see if this works any better > for you. > > Currently I'll try tor reproduce this issue locally and will give you an > update as soon as I find anything which might help to get around this > issue. > > bye, > Sumit > >> *SSSD* >> >> [root at ipaserver1 ~]# cat /etc/sssd/sssd.conf >> [domain/linux.adexample.com] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = linux.adexample.com >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipaserver1.linux.adexample.com >> chpass_provider = ipa >> ipa_server = ipaserver1.linux.adexample.com >> ldap_tls_cacert = /etc/ipa/ca.crt >> subdomains_provider = ipa >> debug_level = 6 >> [sssd] >> services = nss, pam, ssh, pac >> config_file_version = 2 >> >> domains = linux.adexample.com >> debug_level = 6 >> [nss] >> debug_level = 6 >> [pam] >> debug_level = 6 >> [sudo] >> debug_level = 6 >> [autofs] >> debug_level = 6 >> [ssh] >> debug_level = 6 >> [pac] >> debug_level = 6 >> >> *KRB5* >> >> [root at ipaserver1 ~]# cat /etc/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 = LINUX.ADEXAMPLE.COM >> dns_lookup_realm = false >> dns_lookup_kdc = true >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> LINUX.ADEXAMPLE.COM = { >> kdc = ipaserver1.linux.adexample.com:88 >> master_kdc = ipaserver1.linux.adexample.com:88 >> admin_server = ipaserver1.linux.adexample.com:749 >> default_domain = linux.adexample.com >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ >> ADEXAMPLE.COM/@adexample.com/ >> auth_to_local = DEFAULT >> } >> >> [domain_realm] >> .linux.adexample.com = LINUX.ADEXAMPLE.COM >> linux.adexample.com = LINUX.ADEXAMPLE.COM >> >> [dbmodules] >> LINUX.ADEXAMPLE.COM = { >> db_library = ipadb.so >> } >> >> I have increased the debug level of the IPA components. >> Here are the logs (*krb5_child.log, **ldap_child.log, **log.smbd, >> **log.wb-ADEXAMPLE, >> **log.wb-LINUX, **log.winbindd, **log.winbindd-dc-connect, >> log.winbindd-idmap*, *sssd.log*, *sssd_linux.adexample.com.log*,*sssd_nss.log, >> **sssd_pac.log*, *sssd_pam.log, * >> >> >> >> *sssd_ssh.log, /var/log/secure):https://gist.github.com/anonymous/9006532 >> * >> Any insights on why only Administrator is recognized by the Trust? And why >> extra step on AD was needed? >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > ------------------------------ > > Message: 3 > Date: Mon, 17 Feb 2014 09:46:53 +0100 > From: Pavel B?ezina > To: Steve Dainard > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo denied on first attempt, allowed on > second attempt > Message-ID: <5301CC7D.6050903 at redhat.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/16/2014 01:19 AM, Steve Dainard wrote: >> Just experienced the same issue on Fedora 20: >> >> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on fed20. This >> incident will be reported. >> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld >> [sudo] password for sdainard-admin at miovision.corp: >> [sdainard-admin at miovision.corp@fed20 ~]$ >> >> Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). >> >> /var/log/messages: >> Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall >> daemon... >> Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon. >> >> >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | /Rethink Traffic/ >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------------------------------------------------ >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, >> ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or confidential. >> If you are not the intended recipient, please delete the e-mail and any >> attachments and notify us immediately. >> >> >> On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard > > wrote: >> >> On a Ubuntu 13.10 client after configuring sssd to provide sudo >> service I left the client idle for a few hours. On returning, I >> unlocked the screensaver and did the following: >> >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. >> This incident will be reported. >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> root at ubu1310:/home/miovision.corp/sdainard-admin# >> >> I haven't experienced this on a Fedora 20 or EL client so I'm >> guessing this is something specific to Ubuntu. >> >> I've attached the client sssd log if anyone can point me in the >> right direction. >> >> Thanks, >> >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | /Rethink Traffic/ >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------------------------------------------------ >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, >> Kitchener, ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or >> confidential. If you are not the intended recipient, please delete >> the e-mail and any attachments and notify us immediately. > Hi, > provided logs did not reveal anything bad. Can you also attach > sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and > sudo version do you run? > > Is this always reproducible or it happens only sporadically? > > Thanks. > > > > ------------------------------ > > Message: 4 > Date: Mon, 17 Feb 2014 15:03:00 +0100 > From: Jakub Hrozek > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] authentication against compat > Message-ID: <20140217140300.GE7979 at hendrix.brq.redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Fri, Feb 14, 2014 at 09:36:33AM +0200, Alexander Bokovoy wrote: >> On Thu, 13 Feb 2014, Steve Dainard wrote: >>> I don't think this is an issue of bugs or documentation, more of design. >>> Perhaps there's someplace other than a users list this belongs in but: >>> >>> If IPA is a centrally managed identity and access control system, should >>> these configurations not be passed to clients, rather than every client >>> needing configuration changes post join? Obviously I can automate config >>> changes, but why would I want to? I don't think sudoers priv is a fringe >>> case, its pretty much THE case for access/admin control. I cringe to >>> compare to a Windows domain, but I don't have to manually tell a domain >>> client that it should respect the rules I set on a domain controller, I >>> joined it to the domain for this reason. >> When majority of expected features are already implemented, it is easy >> to fall into assumption that everything has to be complete from start. >> That's understandable but we are dealing with a living and evolving >> project where a feature addition often means integrating across multiple >> actual free software projects, all with their own priorities and >> schedules, step by step, or things will never happen. >> >> SUDO integration is not an exception here. First we needed to expand >> SUDO's support for external plugins. When SUDO data was placed in LDAP, >> it appeared that existing schema isn't really optimal, so FreeIPA schema >> was designed better (but incompatible with existing one from SUDO LDAP), >> but required a compatibility part to work with existing SUDO LDAP >> plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO >> LDAP schema as it gave SSSD wider coverage of SUDO support. Now we >> implemented support for native FreeIPA schema. The next step is to >> integrate configuration of it in ipa-client-install so that clients will >> get set up properly if there are SUDO rules configured on the server or >> ipa-client-install was actually given a bless from the admin (via CLI >> option or answering a question). >> >> It takes time and effort. Unsurprisingly, this is a relatively minor >> feature in the grand picture because we have dozens of such features all >> asking for attention and time, and our development teams are not >> expanding infinitely regardless how we all wished. :) >> >> Any help is welcome! > By the way the native sudo backend is being worked on actively by an > external contributor in the form of a thesis. We expect to have it > implemented by May. > > > > ------------------------------ > > Message: 5 > Date: Mon, 17 Feb 2014 15:08:10 +0100 > From: Jakub Hrozek > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up sudo > Message-ID: <20140217140810.GG7979 at hendrix.brq.redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Thu, Feb 13, 2014 at 06:30:37PM -0500, Dmitri Pal wrote: >> On 02/13/2014 06:23 PM, Todd Maugh wrote: >>> and If I am configuring the sud-ldap.conf >>> >>> >>> what should it look like does any one have an example? >>> >> You have two options. Sudo can be integrated with SSSD or not. >> If you want SUDO to be integrated then this should help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > Also man sssd-sudo should have some examples. > > > > ------------------------------ > > Message: 6 > Date: Mon, 17 Feb 2014 14:25:57 +0000 > From: Andrew Holway > To: Todd Maugh > Cc: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Setting up sudo > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > It actually took me a long time to find this information. It is poorly > documented but this mailing list post works. :) > > https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html > > > > On 13 February 2014 23:17, Todd Maugh wrote: >> the documentation is kinda vague on some parts >> >> from the documentation: >> >> Because the sudo information is not available anonymously over LDAP by >> default, Identity Management defines a default sudo user, >> uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo >> configuration file, /etc/sud-ldap.conf. >> >> so is this user supposed to already pre defined. or do I need to create the >> user, and then modify them >> >> thanks >> >> -Todd >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 67, Issue 88 > ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From tde3000 at gmail.com Mon Feb 17 20:04:01 2014 From: tde3000 at gmail.com (John Stein) Date: Mon, 17 Feb 2014 22:04:01 +0200 Subject: [Freeipa-users] Installing FreeIPA 3.1 -> 3.3 On RHEL Message-ID: Hi all. The newest IPA version that exists in the RHN repository is 3.0.0-37. I would like to install IPA version greater then 3.0 on RHEL 6.x. How would you recommend installing newer versions? Using Fedora repository, EPEL or just download the tarball and build it? thank you very much, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 17 20:12:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Feb 2014 22:12:39 +0200 Subject: [Freeipa-users] Installing FreeIPA 3.1 -> 3.3 On RHEL In-Reply-To: References: Message-ID: <20140217201239.GL16644@redhat.com> On Mon, 17 Feb 2014, John Stein wrote: >Hi all. >The newest IPA version that exists in the RHN repository is 3.0.0-37. I >would like to install IPA version greater then 3.0 on RHEL 6.x. >How would you recommend installing newer versions? Using Fedora repository, >EPEL or just download the tarball and build it? RHEL 6.x lacks many of the dependencies required for IPA 3.3. Newer MIT Kerberos (with API and ABI change for KDC database driver and many other changes required for trusts and two-factor authentication), newer Dogtag which relies on several dozens of Java packages and newer tomcat, systemd (we use socket activation and tmpfiles.d a lot), newer SSSD. Kerberos ccache stored in the kernel space (KEYRING ccache type) requires changes at kernel level which are also needed for kerberized NFSv4 for trusts as AD users have large Kerebros tickets when they are members of many groups and so on. There are many dependencies and not all of them could be satisfied through a simple recompile. -- / Alexander Bokovoy From sdainard at miovision.com Mon Feb 17 21:29:12 2014 From: sdainard at miovision.com (Steve Dainard) Date: Mon, 17 Feb 2014 16:29:12 -0500 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: <5301CC7D.6050903@redhat.com> References: <5301CC7D.6050903@redhat.com> Message-ID: I can't reproduce consistently on any OS including Fedora 20, but I was able to trigger the issue on a Ubuntu 13.10 client. sssd: 1.11.1 sudo: 1.8.6p3-0ubuntu3 I have only just enabled the sudo logging so it should only contain the events below: sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: root at ubu1310:/home/miovision.corp/sdainard-admin# Files attached outside of list. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 17, 2014 at 3:46 AM, Pavel B?ezina wrote: > On 02/16/2014 01:19 AM, Steve Dainard wrote: > >> Just experienced the same issue on Fedora 20: >> >> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on fed20. This >> incident will be reported. >> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld >> [sudo] password for sdainard-admin at miovision.corp: >> [sdainard-admin at miovision.corp@fed20 ~]$ >> >> Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). >> >> /var/log/messages: >> Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall >> daemon... >> Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall >> daemon. >> >> >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | /Rethink Traffic/ >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------------------------------------------------ >> >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, >> ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or confidential. >> If you are not the intended recipient, please delete the e-mail and any >> attachments and notify us immediately. >> >> >> On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard > > wrote: >> >> On a Ubuntu 13.10 client after configuring sssd to provide sudo >> service I left the client idle for a few hours. On returning, I >> unlocked the screensaver and did the following: >> >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. >> This incident will be reported. >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> root at ubu1310:/home/miovision.corp/sdainard-admin# >> >> I haven't experienced this on a Fedora 20 or EL client so I'm >> guessing this is something specific to Ubuntu. >> >> I've attached the client sssd log if anyone can point me in the >> right direction. >> >> Thanks, >> >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | /Rethink Traffic/ >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------------------------------------ >> ------------ >> >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, >> Kitchener, ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or >> confidential. If you are not the intended recipient, please delete >> the e-mail and any attachments and notify us immediately. >> > > Hi, > provided logs did not reveal anything bad. Can you also attach > sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and sudo > version do you run? > > Is this always reproducible or it happens only sporadically? > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Feb 17 21:59:24 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 17 Feb 2014 21:59:24 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: References: <5301CC7D.6050903@redhat.com>, Message-ID: I seem to have got a RHEL6 workstation doing smbclient to an IPA samba enabled server OK. Is there a way to limit some users to CIFS only in IPA? Also however my AD connected windows7 machine with winsync and passsync in place to IPA wont connect. It doesnt seem to like the password....or user, unsure... regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 17 22:21:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 00:21:18 +0200 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: References: <5301CC7D.6050903@redhat.com> Message-ID: <20140217222118.GA25560@redhat.com> On Mon, 17 Feb 2014, Steven Jones wrote: >I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >enabled server OK. > > >Is there a way to limit some users to CIFS only in IPA? If you file system supports POSIX ACLs then simply set limits at the file system level, it should work fine. http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html >Also however my AD connected windows7 machine with winsync and passsync >in place to IPA wont connect. It doesnt seem to like the password....or >user, unsure... It doesn't like SID of that user and therefore doesn't think it is the same user. There might be other reasons too, as we still haven't settled down all bits to enable proper Windows integration for CIFS file serving. -- / Alexander Bokovoy From Steven.Jones at vuw.ac.nz Mon Feb 17 22:49:02 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 17 Feb 2014 22:49:02 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <20140217222118.GA25560@redhat.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> Message-ID: <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com> Hi, So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? Ergo I have to remove IPA off the samba server? regards Steven Jones ________________________________________ From: Alexander Bokovoy Sent: Tuesday, 18 February 2014 11:21 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA On Mon, 17 Feb 2014, Steven Jones wrote: >I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >enabled server OK. > > >Is there a way to limit some users to CIFS only in IPA? If you file system supports POSIX ACLs then simply set limits at the file system level, it should work fine. http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html >Also however my AD connected windows7 machine with winsync and passsync >in place to IPA wont connect. It doesnt seem to like the password....or >user, unsure... It doesn't like SID of that user and therefore doesn't think it is the same user. There might be other reasons too, as we still haven't settled down all bits to enable proper Windows integration for CIFS file serving. -- / Alexander Bokovoy From dpal at redhat.com Mon Feb 17 23:04:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 17 Feb 2014 18:04:15 -0500 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <5302956F.5010809@redhat.com> On 02/17/2014 05:49 PM, Steven Jones wrote: > Hi, > > So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? > > Ergo I have to remove IPA off the samba server? I think the setup when you have sync in place is a bit crafty. I know that people made it work in the past but with some assumptions that this is not an SSO. I mean you can't use a Window system and access Samba FS share when Samba FS is a member of IPA and IPA is in sync relations because user on Windows and user in IPA are two different users though they have same name Samba FS can't match the windows SID of the Windows user to the SID of the IPA user because there is no SID for IPA user. But on the other side I know that one can make Samba FS work with IPA, there have been articles about it. I am not sure what is the expectation about the clients in this case. The solution that we are working on is based on the trust. This part is not ready yet. Once ready Samba FS can be a member of the IPA domain, IPA would trust AD and then users from AD running Windows systems would be able to directly use Samba FS. This feature is in development right now. > regards > > Steven Jones > > ________________________________________ > From: Alexander Bokovoy > Sent: Tuesday, 18 February 2014 11:21 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On Mon, 17 Feb 2014, Steven Jones wrote: >> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >> enabled server OK. >> >> >> Is there a way to limit some users to CIFS only in IPA? > If you file system supports POSIX ACLs then simply set limits at the > file system level, it should work fine. > > http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html > >> Also however my AD connected windows7 machine with winsync and passsync >> in place to IPA wont connect. It doesnt seem to like the password....or >> user, unsure... > It doesn't like SID of that user and therefore doesn't think it is the > same user. There might be other reasons too, as we still haven't settled > down all bits to enable proper Windows integration for CIFS file > serving. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From genadipost at gmail.com Mon Feb 17 23:11:38 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Tue, 18 Feb 2014 01:11:38 +0200 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: <20140217083433.GI15419@localhost.localdomain> References: <20140217083433.GI15419@localhost.localdomain> Message-ID: Thank you for the help! I have preformed downgrade: yum downgrade samba4* [root at ipaserver1 ~]# rpm -qa | grep samb samba4-python-4.0.0-58.el6.rc4.x86_64 samba4-winbind-4.0.0-58.el6.rc4.x86_64 samba4-common-4.0.0-58.el6.rc4.x86_64 samba4-winbind-clients-4.0.0-58.el6.rc4.x86_64 samba4-libs-4.0.0-58.el6.rc4.x86_64 samba4-client-4.0.0-58.el6.rc4.x86_64 samba4-4.0.0-58.el6.rc4.x86_64 And it worked ! *I am now able to perform login via "ssh" and su on to the ipaserver with AD users:* [root at ipaserver1 ~]# su Genadi at ADEXAMPLE.COM sh-4.1$ *and wbinfo and getent return values:* [root at ipaserver1 ~]# wbinfo -u ADEXAMPLE\administrator ADEXAMPLE\guest ADEXAMPLE\genadi ADEXAMPLE\krbtgt ADEXAMPLE\linux$ ADEXAMPLE\daniel [root at ipaserver1 ~]# wbinfo -g admins editors default smb group ad_users ADEXAMPLE\domain computers ADEXAMPLE\domain controllers ADEXAMPLE\schema admins ADEXAMPLE\enterprise admins ADEXAMPLE\domain admins ADEXAMPLE\domain users ADEXAMPLE\domain guests ADEXAMPLE\group policy creator owners ADEXAMPLE\read-only domain controllers ADEXAMPLE\enterprise read-only domain controllers ADEXAMPLE\dnsupdateproxy [root at ipaserver1 ~]# getent passwd Genadi at ADEXAMPLE.COM genadi at adexample.com:*:699001000:699001000::/home/adexample.com/genadi: *After this success, i have tried to execute a login on client machine (using AD user), but it did not work:* [root at ipaclient1 ~]# su Genadi at ADEXAMPLE.COM su: user Genadi at ADEXAMPLE.COM does not exist *Also wbinfo and getent do not return value:* [root at ipaclient1 ~]# wbinfo -u [root at ipaclient1 ~]# wbinfo -g [root at ipaclient1 ~]# getent passwd Genadi at ADEXAMPLE.COM *Therefore i have preformed downgrade:* yum downgrade samba4* [root at ipaclient1 ~]# rpm -qa | grep samb samba-winbind-clients-3.6.9-167.el6_5.x86_64 samba-common-3.6.9-167.el6_5.x86_64 samba-winbind-3.6.9-167.el6_5.x86_64 samba4-libs-4.0.0-58.el6.rc4.x86_64 *After the downgrade the login attempt still failed:* [root at ipaclient1 ~]# su Genadi at ADEXAMPLE.COM su: user Genadi at ADEXAMPLE.COM does not exist *I wonder if the fact that ipa-windbind-client is 3.6.9, is the cause.* *Also here are the client configuration file:* *sssd* [root at ipaclient1 ~]# cat /etc/sssd/sssd.conf [domain/linux.adexample.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.adexample.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaclient1.linux.adexample.com chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipaserver1.linux.adexample.com ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa [sssd] services = nss, pam, ssh, pac config_file_version = 2 domains = linux.adexample.com [nss] [pam] [sudo] [autofs] [ssh] [pac] *krb5* [root at ipaclient1 ~]# cat /etc/krb5.conf #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = LINUX.ADEXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] LINUX.ADEXAMPLE.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ ADEXAMPLE.COM/@adexample.com/ auth_to_local = DEFAULT } [domain_realm] .linux.adexample.com = LINUX.ADEXAMPLE.COM linux.adexample.com = LINUX.ADEXAMPLE.COM *And again - Thanks you. I was stuck on it for log time.* 2014-02-17 10:34 GMT+02:00 Sumit Bose : > On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote: > > I have seen threads where opened on trust issues: > > "AD - Freeipa trust confusion" > > "Cross domain trust" > > "Cannot loging via SSH with AD user TO IPA Domain" - which I opened. > > > > It looks like after creation of trust, TGT ticket can be issued from AD, > > but "su" and "ssh" do not allow a log in with AD user. > > I'm not sure if a conclusion has been reached on this subject. > > > > I gave it a try again and attempted to create a trust with IPA as a DNS > > subdomain of AD. > > I followed : > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html > > > > AD domain: ADEXAMPLE.COM > > IPA subdoamin: LINUX.ADEXAMPLE.COM > > > > When i finished the necessary steps i attempted to retrieve a TGT from AD > > (while logged in to IPA server): > > > > [root at ipaserver1 sbin]# kinit Administrator at ADEXAMPLE.COM > > Password for Administrator at ADEXAMPLE.COM: > > [root at ipaserver1 sbin]# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: Administrator at ADEXAMPLE.COM > > > > Valid starting Expires Service principal > > 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/ADEXAMPLE.COM at ADEXAMPLE.COM > > renew until 02/15/14 07:50:21 > > > > But logging in by "ssh" and "su" ended in failure: > > > > login as: Administrator at ADEXAMPLE.COM > > Administrator at ADDC.COM@192.168.227.201's password: > > Access denied > > > > After reading > > > http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini > > did the following on the AD server: > > > > Administrative Tools -> Active Directory Domains and Trust -> > > adexample.com(right click) -> Properties -> Trust -> Domain Trusted by > > this domain > > (outgoing trust) -> Properties -> General -> Validate > > > > *After doing this i was able to login via "ssh" and "su" with > > "Administrator" **user :* > > > > login as: Administrator at ADEXAMPLE.COM > > Administrator at ADEXAMPLE.COM@192.168.227.201's password: > > Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 > > Could not chdir to home directory /home/adexample.com/administrator: No > > such file or directory > > /usr/bin/xauth: error in locking authority file /home/ > > adexample.com/administrator/.Xauthority > > -sh-4.1$ > > > > *But still not able to login with other AD accounts:* > > > > [root at ipaserver1 sbin]# su Genadi at ADEXAMPLE.COM > > su: user Genadi at ADEXAMPLE.COM does not exist > > > > After reading the other threads, ill try and provide as much information > as > > i can: > > > > *wbinfo -u does not return values.* > > [root at ipaserver1 sbin]# wbinfo -u > > [root at ipaserver1 sbin]# > > > > *wbinfo -u output:* > > [root at ipaserver1 sbin]# wbinfo -g > > admins > > editors > > default smb group > > ad_users > > > > *wbinfo --online-status shows ADEXAMPLE is offline* > > [root at ipaserver1 ~]# wbinfo --online-status > > BUILTIN : online > > LINUX : online > > ADEXAMPLE : offline > > > > *getent for Administrator does return value.* > > [root at ipaserver1 sbin]# getent passwd Administrator at ADEXAMPLE.COM > > administrator at adexample.com:*:699000500:699000500::/home/ > > adexample.com/administrator: > > > > *getent for other AD users does not return value.* > > [root at ipaserver1 sbin]# getent passwd Genadi at ADEXAMPLE.COM > > [root at ipaserver1 sbin]# > > > > > > *System info/configurations:* > > > > [root at ipaserver1 ~]# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) > > > > [root at ipaserver1 sbin]# rpm -qa | grep ipa > > ipa-python-3.0.0-37.el6.x86_64 > > ipa-client-3.0.0-37.el6.x86_64 > > libipa_hbac-python-1.9.2-129.el6.x86_64 > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-server-trust-ad-3.0.0-37.el6.x86_64 > > libipa_hbac-1.9.2-129.el6.x86_64 > > ipa-admintools-3.0.0-37.el6.x86_64 > > ipa-server-selinux-3.0.0-37.el6.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > ipa-server-3.0.0-37.el6.x86_64 > > python-iniparse-0.3.1-2.1.el6.noarch > > > > [root at ipaserver1 ~]# rpm -qa | grep sssd > > sssd-1.9.2-129.el6.x86_64 > > sssd-client-1.9.2-129.el6.x86_64 > > > > [root at ipaserver1 sbin]# rpm -qa | grep samb > > samba4-common-4.0.0-60.el6_5.rc4.x86_64 > > samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 > > samba4-libs-4.0.0-60.el6_5.rc4.x86_64 > > samba4-python-4.0.0-60.el6_5.rc4.x86_64 > > samba4-4.0.0-60.el6_5.rc4.x86_64 > > samba4-client-4.0.0-60.el6_5.rc4.x86_64 > > samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 > > Thank you very much for the detailed report. Looks like you are hit by > the 'NT_STATUS_INVALID_PARAMETER_MIX' issue (see log.wb-ADEXAMPLE). We > are currently investigating this issue. > > I you would like to help it would be nice if you can try to downgrade > the samba4 packages to the -58 release and see if this works any better > for you. > > Currently I'll try tor reproduce this issue locally and will give you an > update as soon as I find anything which might help to get around this > issue. > > bye, > Sumit > > > > > *SSSD* > > > > [root at ipaserver1 ~]# cat /etc/sssd/sssd.conf > > [domain/linux.adexample.com] > > > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = linux.adexample.com > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = ipaserver1.linux.adexample.com > > chpass_provider = ipa > > ipa_server = ipaserver1.linux.adexample.com > > ldap_tls_cacert = /etc/ipa/ca.crt > > subdomains_provider = ipa > > debug_level = 6 > > [sssd] > > services = nss, pam, ssh, pac > > config_file_version = 2 > > > > domains = linux.adexample.com > > debug_level = 6 > > [nss] > > debug_level = 6 > > [pam] > > debug_level = 6 > > [sudo] > > debug_level = 6 > > [autofs] > > debug_level = 6 > > [ssh] > > debug_level = 6 > > [pac] > > debug_level = 6 > > > > *KRB5* > > > > [root at ipaserver1 ~]# cat /etc/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 = LINUX.ADEXAMPLE.COM > > dns_lookup_realm = false > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > > > [realms] > > LINUX.ADEXAMPLE.COM = { > > kdc = ipaserver1.linux.adexample.com:88 > > master_kdc = ipaserver1.linux.adexample.com:88 > > admin_server = ipaserver1.linux.adexample.com:749 > > default_domain = linux.adexample.com > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ > > ADEXAMPLE.COM/@adexample.com/ > > auth_to_local = DEFAULT > > } > > > > [domain_realm] > > .linux.adexample.com = LINUX.ADEXAMPLE.COM > > linux.adexample.com = LINUX.ADEXAMPLE.COM > > > > [dbmodules] > > LINUX.ADEXAMPLE.COM = { > > db_library = ipadb.so > > } > > > > I have increased the debug level of the IPA components. > > Here are the logs (*krb5_child.log, **ldap_child.log, **log.smbd, > > **log.wb-ADEXAMPLE, > > **log.wb-LINUX, **log.winbindd, **log.winbindd-dc-connect, > > log.winbindd-idmap*, *sssd.log*, > *sssd_linux.adexample.com.log*,*sssd_nss.log, > > **sssd_pac.log*, *sssd_pam.log, * > > > > > > > > *sssd_ssh.log, /var/log/secure): > https://gist.github.com/anonymous/9006532 > > * > > Any insights on why only Administrator is recognized by the Trust? And > why > > extra step on AD was needed? > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Feb 17 23:34:12 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 17 Feb 2014 23:34:12 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <5302956F.5010809@redhat.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com> Message-ID: <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com> Can we be clear here, Im not after SSO as such, I can sign in with the AD password but that is failing. Otherwise if I read you correctly I cant use IPA controlled samba with AD controlled windows hosts at all? So Im better to de-IPA samba and go back to the old samba method with a local password? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 18 February 2014 12:04 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA On 02/17/2014 05:49 PM, Steven Jones wrote: > Hi, > > So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? > > Ergo I have to remove IPA off the samba server? I think the setup when you have sync in place is a bit crafty. I know that people made it work in the past but with some assumptions that this is not an SSO. I mean you can't use a Window system and access Samba FS share when Samba FS is a member of IPA and IPA is in sync relations because user on Windows and user in IPA are two different users though they have same name Samba FS can't match the windows SID of the Windows user to the SID of the IPA user because there is no SID for IPA user. But on the other side I know that one can make Samba FS work with IPA, there have been articles about it. I am not sure what is the expectation about the clients in this case. The solution that we are working on is based on the trust. This part is not ready yet. Once ready Samba FS can be a member of the IPA domain, IPA would trust AD and then users from AD running Windows systems would be able to directly use Samba FS. This feature is in development right now. > regards > > Steven Jones > > ________________________________________ > From: Alexander Bokovoy > Sent: Tuesday, 18 February 2014 11:21 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On Mon, 17 Feb 2014, Steven Jones wrote: >> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >> enabled server OK. >> >> >> Is there a way to limit some users to CIFS only in IPA? > If you file system supports POSIX ACLs then simply set limits at the > file system level, it should work fine. > > http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html > >> Also however my AD connected windows7 machine with winsync and passsync >> in place to IPA wont connect. It doesnt seem to like the password....or >> user, unsure... > It doesn't like SID of that user and therefore doesn't think it is the > same user. There might be other reasons too, as we still haven't settled > down all bits to enable proper Windows integration for CIFS file > serving. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Tue Feb 18 01:32:49 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 18 Feb 2014 01:32:49 +0000 Subject: [Freeipa-users] extending IPA schema and then pulling that attribute from AD via winsync In-Reply-To: <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com>, <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <67e9a71acc614ccdbdf79a4691ed3b39@SINPR04MB298.apcprd04.prod.outlook.com> Hi, On a different note if I want to have a custom field/attribute in IPA, I take it I can "extend the schema" and add this ? as the correct term? Can that attribute be populated from AD via the winsync agreement? regards Steven From barrykfl at gmail.com Tue Feb 18 03:51:26 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 18 Feb 2014 11:51:26 +0800 Subject: [Freeipa-users] Allow freeipa send password to user Message-ID: Is it possible to set allow password to send to user after user request. I used one of the self password service pwm but it seem it is not compatible to retriveal of password using cert request / Answer and questions retrieval thks barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan.Petersson at sscspace.com Tue Feb 18 07:18:48 2014 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Tue, 18 Feb 2014 07:18:48 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com>, <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <558C15177F5E714F83334217C9A197DF014D126BFB@SSC-MBX1.ssc.internal> One solution that i have tested myself is to have IPA and AD sync with Samba as a server in a 2012 R2 Server AD. For shared directories used both by Windows and Linux clients like Home i used NFS 4 with Kerberos for Linux and Samba ADS for Windows. Same user could log in from both Windows and Linux with same password through winsync and passsync and get secured access with proper permissions on directories and files. Tested this setup out while i wait for IPA being able to handle all user accounts an resources in an IPA - AD trust. Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Tuesday, February 18, 2014 00:34 To: freeipa-users at redhat.com; dpal at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA Can we be clear here, Im not after SSO as such, I can sign in with the AD password but that is failing. Otherwise if I read you correctly I cant use IPA controlled samba with AD controlled windows hosts at all? So Im better to de-IPA samba and go back to the old samba method with a local password? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 18 February 2014 12:04 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA On 02/17/2014 05:49 PM, Steven Jones wrote: > Hi, > > So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? > > Ergo I have to remove IPA off the samba server? I think the setup when you have sync in place is a bit crafty. I know that people made it work in the past but with some assumptions that this is not an SSO. I mean you can't use a Window system and access Samba FS share when Samba FS is a member of IPA and IPA is in sync relations because user on Windows and user in IPA are two different users though they have same name Samba FS can't match the windows SID of the Windows user to the SID of the IPA user because there is no SID for IPA user. But on the other side I know that one can make Samba FS work with IPA, there have been articles about it. I am not sure what is the expectation about the clients in this case. The solution that we are working on is based on the trust. This part is not ready yet. Once ready Samba FS can be a member of the IPA domain, IPA would trust AD and then users from AD running Windows systems would be able to directly use Samba FS. This feature is in development right now. > regards > > Steven Jones > > ________________________________________ > From: Alexander Bokovoy > Sent: Tuesday, 18 February 2014 11:21 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On Mon, 17 Feb 2014, Steven Jones wrote: >> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >> enabled server OK. >> >> >> Is there a way to limit some users to CIFS only in IPA? > If you file system supports POSIX ACLs then simply set limits at the > file system level, it should work fine. > > http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html > >> Also however my AD connected windows7 machine with winsync and passsync >> in place to IPA wont connect. It doesnt seem to like the password....or >> user, unsure... > It doesn't like SID of that user and therefore doesn't think it is the > same user. There might be other reasons too, as we still haven't settled > down all bits to enable proper Windows integration for CIFS file > serving. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. From barrykfl at gmail.com Tue Feb 18 07:19:18 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 18 Feb 2014 15:19:18 +0800 Subject: [Freeipa-users] Response attribute to allow user unlock and retreval password Message-ID: Dear all: Any attribute allow user to retrieve password and response to unlock and allow to send plain text password.? Regards Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Feb 18 07:43:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 09:43:56 +0200 Subject: [Freeipa-users] Response attribute to allow user unlock and retreval password In-Reply-To: References: Message-ID: <20140218074356.GQ16644@redhat.com> On Tue, 18 Feb 2014, barrykfl at gmail.com wrote: >Dear all: > >Any attribute allow user to retrieve password and response to unlock and >allow to send plain text password.? No, since we do not store plain text passwords. Perhaps you could explain your actual use case? Is it password recovery? Wouldn't password reset work here better? -- / Alexander Bokovoy From sigbjorn at nixtra.com Tue Feb 18 09:05:47 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 18 Feb 2014 10:05:47 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53023FD8.5060103@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D3FF10.3060504@redhat.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> Message-ID: <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> On Mon, February 17, 2014 17:59, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >> >> >> >> On Mon, February 17, 2014 16:34, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>> >>>> >>>> >>>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote: >>>> >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Sigbjorn Lie wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It would seem like we're still encountering some issues. The date has now passed >>>>>>>> for when the old certificate expired, and the "ipa" cli command no longer works. The >>>>>>>> webui is still working just fine. >>>>>>>> >>>>>>>> These are the errors I receive. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> $ ipa user-find >>>>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM" >>>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not >>>>>>>> trusted by the user.) ipa: ERROR: cert validation failed for >>>>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM" >>>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not >>>>>>>> trusted by the user.) ipa: ERROR: cert validation failed for >>>>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM" >>>>>>>> ((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://serveripa03.example.com/ipa/xml, >>>>>>>> https://serveripa01.example.com/ipa/xml, >>>>>>>> https://serveripa02.example.com/ipa/xml >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> This seems more like a client-side issue. Can you confirm that >>>>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb >>>>>>> contains the CA? >>>>>>> >>>>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>>>> >>>>>> >>>>>> >>>>>> The CA seem to be available. I ran the command on ipa01. See below for the output. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the >>>>>> ipa command from a remote machine. >>>>>> >>>>>> >>>>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>>>>> Certificate: >>>>>> Data: >>>>>> Version: 3 (0x2) >>>>>> Serial Number: 1 (0x1) >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >>>>>> Validity: >>>>>> Not Before: Thu Jan 19 19:44:21 2012 >>>>>> Not After : Sun Jan 19 19:44:21 2020 >>>>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM" >>>>>> Subject Public Key Info: >>>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>>> RSA Public Key: >>>>>> Modulus: >>>>>> >>>>>> >>>>>> >>>>> >>>>> Perhaps we can brute force things to see what is going on. We can pass >>>>> some extra options to the ipa tool to get ultra verbose output: >>>>> >>>>> $ ipa -vv -e debug=True user-show admin >>>>> >>>>> >>>>> >>>>> >>>>> The thing to do is to check the server that it is communicating with and >>>>> check /var/log/httpd/errors to see if there is an equivalent error logged there. >>>>> >>>> >>>> I've sent you the full output in private. Could this be the reason for why it fails? >>>> >>>> >>>> >>>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False >>>> >>>> >>>> >>>> Name: Certificate Key Usage >>>> Critical: True >>>> Usages: >>>> Digital Signature >>>> Non-Repudiation >>>> Key Encipherment >>>> Data Encipherment >>>> >>>> >>>> >>> >>> No, that is normal for a server cert. >>> >>> >>> >>> This pretty clearly looks like an SSL trust issue. Is this happening on >>> every client machine you run the ipa tool or just one? >>> >>> You might want to compare the cert in /etc/pki/nssdb with the one on the >>> Apache server. >>> >>> >>> >>> # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' >>> >>> >>> >>> # certutil -L -d /etc/pki/nssdb -n 'IPA CA' >>> >>> >> >> Looks like the same certificate, just with different flags? >> >> >> $ sudo certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > /tmp/ca1 >> $ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > /tmp/ca2 >> $ diff /tmp/ca1 /tmp/ca2 >> 90a91,92 >> >>> Valid CA >>> Trusted CA >>> > > A diff with context would confirm it but I'm assuming this is just the > code-signing trust which won't affect anything in this case. You'll notice that some trust is > CT,C,C and some just CT,C,. The order is SSL, > S/MIME, code signing. > > > On what machine are you trying to use the ipa tool? Is it one of the > masters, all of them, enrolled clients? > It's the same error message when the "ipa" command is run directly on any of the masters. And it's the same error message if I run the "ipa" command on any of the clients. I do not have a working "ipa" command anywhere anymore. > Whatever is going on isn't likely related to the web server Apache > database as you get the same error out of each one. The client log you sent confirmed that it tried > to contact each master. The SSL error we're getting is that the client doesn't trust the CA that > signed the server certificate so this appears to be a problem on the client, which begs the > question: all clients or just this one? > All clients. > > NSS is smart enough to handle multiple certificates, it should pick the > newest one on startup. > Ok. Where do you suggest I continue troubleshooting this issue? Regards, Siggi From sbose at redhat.com Tue Feb 18 09:38:45 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 18 Feb 2014 10:38:45 +0100 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: References: <20140217083433.GI15419@localhost.localdomain> Message-ID: <20140218093845.GU15419@localhost.localdomain> On Tue, Feb 18, 2014 at 01:11:38AM +0200, Genadi Postrilko wrote: > Thank you for the help! > I have preformed downgrade: > > yum downgrade samba4* > > [root at ipaserver1 ~]# rpm -qa | grep samb > samba4-python-4.0.0-58.el6.rc4.x86_64 > samba4-winbind-4.0.0-58.el6.rc4.x86_64 > samba4-common-4.0.0-58.el6.rc4.x86_64 > samba4-winbind-clients-4.0.0-58.el6.rc4.x86_64 > samba4-libs-4.0.0-58.el6.rc4.x86_64 > samba4-client-4.0.0-58.el6.rc4.x86_64 > samba4-4.0.0-58.el6.rc4.x86_64 > > And it worked ! > > *I am now able to perform login via "ssh" and su on to the ipaserver with > AD users:* > > [root at ipaserver1 ~]# su Genadi at ADEXAMPLE.COM > sh-4.1$ > > *and wbinfo and getent return values:* > > [root at ipaserver1 ~]# wbinfo -u > ADEXAMPLE\administrator > ADEXAMPLE\guest > ADEXAMPLE\genadi > ADEXAMPLE\krbtgt > ADEXAMPLE\linux$ > ADEXAMPLE\daniel > > [root at ipaserver1 ~]# wbinfo -g > admins > editors > default smb group > ad_users > ADEXAMPLE\domain computers > ADEXAMPLE\domain controllers > ADEXAMPLE\schema admins > ADEXAMPLE\enterprise admins > ADEXAMPLE\domain admins > ADEXAMPLE\domain users > ADEXAMPLE\domain guests > ADEXAMPLE\group policy creator owners > ADEXAMPLE\read-only domain controllers > ADEXAMPLE\enterprise read-only domain controllers > ADEXAMPLE\dnsupdateproxy > > [root at ipaserver1 ~]# getent passwd Genadi at ADEXAMPLE.COM > genadi at adexample.com:*:699001000:699001000::/home/adexample.com/genadi: Thanks a lot for confirming that -58 is working on the FreeIPA server. > > *After this success, i have tried to execute a login on client machine > (using AD user), but it did not work:* > > [root at ipaclient1 ~]# su Genadi at ADEXAMPLE.COM > su: user Genadi at ADEXAMPLE.COM does not exist > > *Also wbinfo and getent do not return value:* > > [root at ipaclient1 ~]# wbinfo -u > [root at ipaclient1 ~]# wbinfo -g > [root at ipaclient1 ~]# getent passwd Genadi at ADEXAMPLE.COM Winbind is not running on the IPA client. SSSD running on the IPA client use a LDAP extended operation to get the basic data about AD users and group. Please try to restart SSSD on the client. If this does not help, please send me the client's SSSD log files. bye, Sumit From jhrozek at redhat.com Tue Feb 18 10:14:26 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 18 Feb 2014 11:14:26 +0100 Subject: [Freeipa-users] A test repository with SSSD 1.11 for RHEL6 Message-ID: <20140218101426.GF7979@hendrix.brq.redhat.com> Hi, we are considering upgrading SSSD in RHEL6 to 1.11.x. With this upgrade, RHEL6 would receive many new features such as: * support for trusted AD domains in the same forest in the AD provider * DNS site discovery for the AD provider * DNS updates and DNS scavenging in the AD provider * simplified sudo configuration in the IPA provider * and more! See the Releases page of SSSD for more details: https://fedorahosted.org/sssd/wiki/Releases To allow our users to test the candidate packages, we have prepared a RHEL6 repository: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ The NVR of these test packages will be lower than official 6.6 packages to keep the upgrade path clean. Using the repository comes with a warning - this is NOT an official Red Hat supported repository. The packages have NOT gone through formal QA, just some testing by SSSD developers. Please report any issues you might encounter with these packages to our mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users Happy testing! From pbrezina at redhat.com Tue Feb 18 10:27:16 2014 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Tue, 18 Feb 2014 11:27:16 +0100 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: References: <5301CC7D.6050903@redhat.com> Message-ID: <53033584.5050402@redhat.com> On 02/17/2014 10:29 PM, Steve Dainard wrote: > I can't reproduce consistently on any OS including Fedora 20, but I was > able to trigger the issue on a Ubuntu 13.10 client. > > sssd: 1.11.1 > > sudo: 1.8.6p3-0ubuntu3 > > I have only just enabled the sudo logging so it should only contain the > events below: > > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.corp/sdainard-admin# > > Files attached outside of list. Hi, thank you for the logs. Can you also send me output of command "id sdainard-admin" (also check if group membership is correct) and definition of the sudo rule please? Also you may want to fix the following (unrelated) warning: Deprecation warning: The option ipa_dyndns_update is deprecated and should not be used in favor of dyndns_update From donald.casson at gmail.com Tue Feb 18 10:42:59 2014 From: donald.casson at gmail.com (Donald Casson) Date: Tue, 18 Feb 2014 20:42:59 +1000 Subject: [Freeipa-users] [SSSD-users] A test repository with SSSD 1.11 for RHEL6 In-Reply-To: <20140218101426.GF7979@hendrix.brq.redhat.com> References: <20140218101426.GF7979@hendrix.brq.redhat.com> Message-ID: Excellent news! Great job guys! Cheers Don On Tue, Feb 18, 2014 at 8:14 PM, Jakub Hrozek wrote: > Hi, > > we are considering upgrading SSSD in RHEL6 to 1.11.x. With this upgrade, > RHEL6 would receive many new features such as: > * support for trusted AD domains in the same forest in the AD > provider > * DNS site discovery for the AD provider > * DNS updates and DNS scavenging in the AD provider > * simplified sudo configuration in the IPA provider > * and more! See the Releases page of SSSD for more details: > https://fedorahosted.org/sssd/wiki/Releases > > To allow our users to test the candidate packages, we have prepared a > RHEL6 repository: > http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ > > The NVR of these test packages will be lower than official 6.6 packages > to keep the upgrade path clean. > > Using the repository comes with a warning - this is NOT an official Red > Hat supported repository. The packages have NOT gone through formal QA, > just some testing by SSSD developers. > > Please report any issues you might encounter with these packages to our > mailing lists: > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > https://lists.fedorahosted.org/mailman/listinfo/sssd-users > > Happy testing! > _______________________________________________ > sssd-users mailing list > sssd-users at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users From shreerajkarulkar at yahoo.com Tue Feb 18 18:29:46 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Tue, 18 Feb 2014 10:29:46 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <52FE7119.1070601@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FAA2B1.3090506@redhat.com> <1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> Message-ID: <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> Rob I am giving it a fresh start and I notice similar issues. 1) I wasn't able to use the "--setup-ca" while running the ipa-replica-install on the replica. It stopped the install after the ntpd step see below. Done configuring NTP daemon (ntpd). A CA is already configured on this system. 2) So I tried my install command again without the --setup-ca option. It went furthur although it completed it show one error see below. ?MY COMMAND: --> ipa-replica-install /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck the skip-conncheck was needed to complete the install. Connections checks were manually done. 14/31]: configuring lockout plugin ? [15/31]: creating indices ? [16/31]: enabling referential integrity plugin ? [17/31]: configuring ssl for ds instance ipa???????? : ERROR??? certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero exit status 1 ? [18/31]: configuring certmap.conf ? [19/31]: configure autobind for root ......................................... 3) The replica installed fine I can access the same database from the replica's website. 4) I cannot add new clients. MY COMMAND: --> ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d ldap.mydomain.com = master ldap2.mydomain.com = replica Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Friday, February 14, 2014 11:40 AM, Rob Crittenden wrote: Shree wrote: > 1) 7839 TCP is open between the master and replica, do I need 7389 udp > also?? What about clients and replica? > I have the following ports opened and tested between master and replica. > --> 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP), 7389 > (TCP) > and? 88 (UDP)? 464 (UDP) > Do I need any more ports opened, I have to work with another team to get > this done, so it will help having all the information. No, this list is enough. Still, it can't connect to it. Seeing the failure output from the connection check might be useful, or at least confirm the same. > 2)I see you skip the connection check, what was failing? :-- Yes my > replica install fails unless I user --skip connection check. I have > tested the connection with the ports mentioned during the install. I don't know what to say, the logs pretty clearly indicate that it can't connect on port 7389. > 3) In the ipareplica-install log this is reported: > > Failed to setup the replication for cloning. :--- Yes but what is the > solution? Fix the firewall. > > 4) And in the debug log: > > :- Also what is the solution for the Java.io error? Same thing. One failure cascades to another. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 18 19:19:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Feb 2014 14:19:06 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <5303B22A.9070709@redhat.com> Shree wrote: > Rob > I am giving it a fresh start and I notice similar issues. > > 1) I wasn't able to use the "--setup-ca" while running the > ipa-replica-install on the replica. It stopped the install after the > ntpd step see below. > > Done configuring NTP daemon (ntpd). > A CA is already configured on this system. This is left over from a previous failed installation. If the CA install fails early enough we don't log the fact that it was installed so the uninstall doesn't clean it up. > 2) So I tried my install command again without the --setup-ca option. It > went furthur although it completed it show one error see below. > > MY COMMAND: --> ipa-replica-install > /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck > the skip-conncheck was needed to complete the install. Connections > checks were manually done. > 14/31]: configuring lockout plugin > [15/31]: creating indices > [16/31]: enabling referential integrity plugin > [17/31]: configuring ssl for ds instance > ipa : ERROR certmonger failed starting to track certificate: > Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p > /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero > exit status 1 > [18/31]: configuring certmap.conf > [19/31]: configure autobind for root > ......................................... Without logs there is no way to diagnose. This could leave you in a situation where the certificate fails to renew in 2 years and IPA suddenly stops working. > 3) The replica installed fine I can access the same database from the > replica's website. > > 4) I cannot add new clients. > MY COMMAND: --> ipa-client-install --domain=mydomain.com > --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d > > ldap.mydomain.com = master > ldap2.mydomain.com = replica No idea without seeing the logs. rob From shreerajkarulkar at yahoo.com Tue Feb 18 19:25:04 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Tue, 18 Feb 2014 11:25:04 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <5303B22A.9070709@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> Message-ID: <1392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> Rob The logs are attached in the email chain. If you need fresh ones, I can try to replicate it again. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Tuesday, February 18, 2014 11:19 AM, Rob Crittenden wrote: Shree wrote: > Rob > I am giving it a fresh start and I notice similar issues. > > 1) I wasn't able to use the "--setup-ca" while running the > ipa-replica-install on the replica. It stopped the install after the > ntpd step see below. > > Done configuring NTP daemon (ntpd). > A CA is already configured on this system. This is left over from a previous failed installation. If the CA install fails early enough we don't log the fact that it was installed so the uninstall doesn't clean it up. > 2) So I tried my install command again without the --setup-ca option. It > went furthur although it completed it show one error see below. > >? MY COMMAND: --> ipa-replica-install > /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck > the skip-conncheck was needed to complete the install. Connections > checks were manually done. > 14/31]: configuring lockout plugin >? ? [15/31]: creating indices >? ? [16/31]: enabling referential integrity plugin >? ? [17/31]: configuring ssl for ds instance > ipa? ? ? ? : ERROR? ? certmonger failed starting to track certificate: > Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p > /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero > exit status 1 >? ? [18/31]: configuring certmap.conf >? ? [19/31]: configure autobind for root > ......................................... Without logs there is no way to diagnose. This could leave you in a situation where the certificate fails to renew in 2 years and IPA suddenly stops working. > 3) The replica installed fine I can access the same database from the > replica's website. > > 4) I cannot add new clients. > MY COMMAND: --> ipa-client-install --domain=mydomain.com > --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d > > ldap.mydomain.com = master > ldap2.mydomain.com = replica No idea without seeing the logs. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From tde3000 at gmail.com Tue Feb 18 19:32:49 2014 From: tde3000 at gmail.com (John Stein) Date: Tue, 18 Feb 2014 21:32:49 +0200 Subject: [Freeipa-users] Installing FreeIPA 3.1 -> 3.3 On RHEL In-Reply-To: <20140217201239.GL16644@redhat.com> References: <20140217201239.GL16644@redhat.com> Message-ID: Thank you for the fast response. Some point i would like to understand better: 1) I understand there is a Big dependencies issue, that's why i want to know if there is a repository that can satisfy those dependencies. 2) Are there core issues (like Kernel version) that can't be resolved for RHEL 6.x.? 3) What is the newest version that i can run on RHEL 6.x without losing my mind? 4) Will it be easier to Install IPA 3.3 on RHEL 7 (beta)? Thanks again, John On Feb 17, 2014 10:12 PM, "Alexander Bokovoy" wrote: > On Mon, 17 Feb 2014, John Stein wrote: > >> Hi all. >> The newest IPA version that exists in the RHN repository is 3.0.0-37. I >> would like to install IPA version greater then 3.0 on RHEL 6.x. >> How would you recommend installing newer versions? Using Fedora >> repository, >> EPEL or just download the tarball and build it? >> > RHEL 6.x lacks many of the dependencies required for IPA 3.3. Newer > MIT Kerberos (with API and ABI change for KDC database driver and many > other changes required for trusts and two-factor authentication), newer > Dogtag which relies on several dozens of Java packages and newer tomcat, > systemd (we use socket activation and tmpfiles.d a lot), newer SSSD. > Kerberos ccache stored in the kernel space (KEYRING ccache type) > requires changes at kernel level which are also needed for kerberized > NFSv4 for trusts as AD users have large Kerebros tickets when they are > members of many groups and so on. > > There are many dependencies and not all of them could be satisfied > through a simple recompile. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 18 19:45:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Feb 2014 14:45:52 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> Message-ID: <5303B870.8030703@redhat.com> Sigbjorn Lie wrote: >> On what machine are you trying to use the ipa tool? Is it one of the >> masters, all of them, enrolled clients? >> > > It's the same error message when the "ipa" command is run directly on any of the masters. > > And it's the same error message if I run the "ipa" command on any of the clients. > > I do not have a working "ipa" command anywhere anymore. Ok, let's test out the cert that ipa is using. Try this on any one of the masters: $ curl https://`hostname`/ipa/xml Should fail with Peer certificate cannot be authenticated with known CA certificates $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml Should succeed in that you get the "you are not logged in" HTML page Ok, now unfortunately curl only handles the sql-style NSS databases so we can't fully reproduce it the same way that the IPA client is doing things, but here is an approximation: # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt $ curl https://`hostname`/ipa/xml You should see the login page HTML If you stick a -v in there it'll give you more verbose output which would be useful if any of these fail in an unexpected way. >> Whatever is going on isn't likely related to the web server Apache >> database as you get the same error out of each one. The client log you sent confirmed that it tried >> to contact each master. The SSL error we're getting is that the client doesn't trust the CA that >> signed the server certificate so this appears to be a problem on the client, which begs the >> question: all clients or just this one? >> > > All clients. > > >> >> NSS is smart enough to handle multiple certificates, it should pick the >> newest one on startup. >> > > Ok. > > Where do you suggest I continue troubleshooting this issue? We can also tackle this on the server side. Let's verify the server cert: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias This is verified on server startup so I expect it to be valid, but doesn't hurt to try. Restarting the Apache process might be something to try as changes to the NSS database aren't picked up until a restart. From rcritten at redhat.com Tue Feb 18 19:52:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Feb 2014 14:52:32 -0500 Subject: [Freeipa-users] Installing FreeIPA 3.1 -> 3.3 On RHEL In-Reply-To: References: <20140217201239.GL16644@redhat.com> Message-ID: <5303BA00.7000304@redhat.com> John Stein wrote: > Thank you for the fast response. > > Some point i would like to understand better: > > 1) I understand there is a Big dependencies issue, that's why i want to > know if there is a repository that can satisfy those dependencies. No, the changes are too vast to make this worthwhile. > 2) Are there core issues (like Kernel version) that can't be resolved > for RHEL 6.x.? Anything can be resolved but at some point the number of changes outweighs any benefits you get. Who is going to support all these newer versions on RHEL 6 after all? > 3) What is the newest version that i can run on RHEL 6.x without losing > my mind? 3.0. > 4) Will it be easier to Install IPA 3.3 on RHEL 7 (beta)? Yes, by far, and easier still since RHEL 7 comes with 3.3.x. rob > > Thanks again, > John > > On Feb 17, 2014 10:12 PM, "Alexander Bokovoy" > wrote: > > On Mon, 17 Feb 2014, John Stein wrote: > > Hi all. > The newest IPA version that exists in the RHN repository is > 3.0.0-37. I > would like to install IPA version greater then 3.0 on RHEL 6.x. > How would you recommend installing newer versions? Using Fedora > repository, > EPEL or just download the tarball and build it? > > RHEL 6.x lacks many of the dependencies required for IPA 3.3. Newer > MIT Kerberos (with API and ABI change for KDC database driver and many > other changes required for trusts and two-factor authentication), newer > Dogtag which relies on several dozens of Java packages and newer tomcat, > systemd (we use socket activation and tmpfiles.d a lot), newer SSSD. > Kerberos ccache stored in the kernel space (KEYRING ccache type) > requires changes at kernel level which are also needed for kerberized > NFSv4 for trusts as AD users have large Kerebros tickets when they are > members of many groups and so on. > > There are many dependencies and not all of them could be satisfied > through a simple recompile. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From abokovoy at redhat.com Tue Feb 18 19:59:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Feb 2014 21:59:30 +0200 Subject: [Freeipa-users] Installing FreeIPA 3.1 -> 3.3 On RHEL In-Reply-To: References: <20140217201239.GL16644@redhat.com> Message-ID: <20140218195930.GA9533@redhat.com> On Tue, 18 Feb 2014, John Stein wrote: >Thank you for the fast response. > >Some point i would like to understand better: > >1) I understand there is a Big dependencies issue, that's why i want to >know if there is a repository that can satisfy those dependencies. There is no repository for that. > >2) Are there core issues (like Kernel version) that can't be resolved for >RHEL 6.x.? I've mentioned them below already. The code we need from the kernel is in 3.11-3.12. You can read release pages to see additions in each of major releases after 3.0: http://www.freeipa.org/page/Releases/3.1.0 http://www.freeipa.org/page/Releases/3.2.0 http://www.freeipa.org/page/Releases/3.3.0 Practically, 3.1 introduced dogtag10 dependency, 3.2 -- new 389-ds, MIT Kerberos, and Samba versions, and hard require on systemd, 3.3 -- new slapi-nis version and SSSD. >3) What is the newest version that i can run on RHEL 6.x without losing my >mind? The version you already have in RHEL 6.5, 3.0, is the last one that can be used on RHEL 6.x for sure. >4) Will it be easier to Install IPA 3.3 on RHEL 7 (beta)? IPA 3.3 is part of RHEL 7.0 beta already. > >Thanks again, >John >On Feb 17, 2014 10:12 PM, "Alexander Bokovoy" wrote: > >> On Mon, 17 Feb 2014, John Stein wrote: >> >>> Hi all. >>> The newest IPA version that exists in the RHN repository is 3.0.0-37. I >>> would like to install IPA version greater then 3.0 on RHEL 6.x. >>> How would you recommend installing newer versions? Using Fedora >>> repository, >>> EPEL or just download the tarball and build it? >>> >> RHEL 6.x lacks many of the dependencies required for IPA 3.3. Newer >> MIT Kerberos (with API and ABI change for KDC database driver and many >> other changes required for trusts and two-factor authentication), newer >> Dogtag which relies on several dozens of Java packages and newer tomcat, >> systemd (we use socket activation and tmpfiles.d a lot), newer SSSD. >> Kerberos ccache stored in the kernel space (KEYRING ccache type) >> requires changes at kernel level which are also needed for kerberized >> NFSv4 for trusts as AD users have large Kerebros tickets when they are >> members of many groups and so on. >> >> There are many dependencies and not all of them could be satisfied >> through a simple recompile. >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From sdainard at miovision.com Tue Feb 18 21:32:01 2014 From: sdainard at miovision.com (Steve Dainard) Date: Tue, 18 Feb 2014 16:32:01 -0500 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: <53033584.5050402@redhat.com> References: <5301CC7D.6050903@redhat.com> <53033584.5050402@redhat.com> Message-ID: Hi Pavel, Very interesting, my IPA group membership in ad_admins isn't shown by that command on first run (new login) sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin at miovision.corp) gid=799002462(sdainard-admin at miovision.corp) groups=799002462(sdainard-admin at miovision.corp ),799001380(accounting-share-access at miovision.corp ),799001417(protected-share-access at miovision.corp),799000519(enterprise admins at miovision.corp),799001416(hr-share-access at miovision.corp),799000512(domain admins at miovision.corp),799000513(domain users at miovision.corp),799002464(it - admins at miovision.corp),799002469(kloperators at miovision.corp ),799002468(kladmins at miovision.corp) sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. But after attempting the sudo command my groups do contain the IPA groups admins,ad_admins: sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin at miovision.corp) gid=799002462(sdainard-admin at miovision.corp) groups=799002462(sdainard-admin at miovision.corp ),799001380(accounting-share-access at miovision.corp ),799001417(protected-share-access at miovision.corp),799000519(enterprise admins at miovision.corp),799001416(hr-share-access at miovision.corp),799000512(domain admins at miovision.corp),799000513(domain users at miovision.corp),799002464(it - admins at miovision.corp),799002469(kloperators at miovision.corp ),799002468(kladmins at miovision.corp), *1768200000(admins),1768200004(ad_admins)* sdainard-admin at miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-admin at miovision.corp: root at ubu1310:/home/miovision.corp/sdainard-admin# Sudo rule (I had to create this, apparently its a default rule, but didn't exist in my install on RHEL7 beta): Rule name: All Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all User Groups: ad_admins I saw the new dns update option (and refresh timers!), thanks. *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Tue, Feb 18, 2014 at 5:27 AM, Pavel B?ezina wrote: > On 02/17/2014 10:29 PM, Steve Dainard wrote: > >> I can't reproduce consistently on any OS including Fedora 20, but I was >> able to trigger the issue on a Ubuntu 13.10 client. >> >> sssd: 1.11.1 >> >> sudo: 1.8.6p3-0ubuntu3 >> >> I have only just enabled the sudo logging so it should only contain the >> events below: >> >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. >> This incident will be reported. >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> root at ubu1310:/home/miovision.corp/sdainard-admin# >> >> Files attached outside of list. >> > > Hi, > thank you for the logs. Can you also send me output of command "id > sdainard-admin" (also check if group membership is correct) and definition > of the sudo rule please? > > Also you may want to fix the following (unrelated) warning: > Deprecation warning: The option ipa_dyndns_update is deprecated and should > not be used in favor of dyndns_update > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 18 21:44:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 18 Feb 2014 16:44:30 -0500 Subject: [Freeipa-users] Allow freeipa send password to user In-Reply-To: References: Message-ID: <5303D43E.7010601@redhat.com> On 02/17/2014 10:51 PM, barrykfl at gmail.com wrote: > Is it possible to set allow password to send to user after user request. > > I used one of the self password service pwm but it seem it is not > compatible to retriveal of password > using cert request / Answer and questions retrieval > > thks > > barry > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Passwords can't be sent to the user. You can using administrative account set a new password (i.e. do an admin reset) and send it to the user but then user will be asked to change it on the first authentication. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Tue Feb 18 22:17:59 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 19 Feb 2014 00:17:59 +0200 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: <20140218093845.GU15419@localhost.localdomain> References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> Message-ID: After i restarted SSSD nothing changed - still cannot login via ssh/su. I have increased debug level to 6: https://gist.github.com/anonymous/9081367 (krb5_child was empty) Thank you. 2014-02-18 11:38 GMT+02:00 Sumit Bose : > On Tue, Feb 18, 2014 at 01:11:38AM +0200, Genadi Postrilko wrote: > > Thank you for the help! > > I have preformed downgrade: > > > > yum downgrade samba4* > > > > [root at ipaserver1 ~]# rpm -qa | grep samb > > samba4-python-4.0.0-58.el6.rc4.x86_64 > > samba4-winbind-4.0.0-58.el6.rc4.x86_64 > > samba4-common-4.0.0-58.el6.rc4.x86_64 > > samba4-winbind-clients-4.0.0-58.el6.rc4.x86_64 > > samba4-libs-4.0.0-58.el6.rc4.x86_64 > > samba4-client-4.0.0-58.el6.rc4.x86_64 > > samba4-4.0.0-58.el6.rc4.x86_64 > > > > And it worked ! > > > > *I am now able to perform login via "ssh" and su on to the ipaserver with > > AD users:* > > > > [root at ipaserver1 ~]# su Genadi at ADEXAMPLE.COM > > sh-4.1$ > > > > *and wbinfo and getent return values:* > > > > [root at ipaserver1 ~]# wbinfo -u > > ADEXAMPLE\administrator > > ADEXAMPLE\guest > > ADEXAMPLE\genadi > > ADEXAMPLE\krbtgt > > ADEXAMPLE\linux$ > > ADEXAMPLE\daniel > > > > [root at ipaserver1 ~]# wbinfo -g > > admins > > editors > > default smb group > > ad_users > > ADEXAMPLE\domain computers > > ADEXAMPLE\domain controllers > > ADEXAMPLE\schema admins > > ADEXAMPLE\enterprise admins > > ADEXAMPLE\domain admins > > ADEXAMPLE\domain users > > ADEXAMPLE\domain guests > > ADEXAMPLE\group policy creator owners > > ADEXAMPLE\read-only domain controllers > > ADEXAMPLE\enterprise read-only domain controllers > > ADEXAMPLE\dnsupdateproxy > > > > [root at ipaserver1 ~]# getent passwd Genadi at ADEXAMPLE.COM > > genadi at adexample.com:*:699001000:699001000::/home/adexample.com/genadi: > > Thanks a lot for confirming that -58 is working on the FreeIPA server. > > > > > *After this success, i have tried to execute a login on client machine > > (using AD user), but it did not work:* > > > > [root at ipaclient1 ~]# su Genadi at ADEXAMPLE.COM > > su: user Genadi at ADEXAMPLE.COM does not exist > > > > *Also wbinfo and getent do not return value:* > > > > [root at ipaclient1 ~]# wbinfo -u > > [root at ipaclient1 ~]# wbinfo -g > > [root at ipaclient1 ~]# getent passwd Genadi at ADEXAMPLE.COM > > Winbind is not running on the IPA client. SSSD running on the IPA client > use a LDAP extended operation to get the basic data about AD users and > group. Please try to restart SSSD on the client. If this does not help, > please send me the client's SSSD log files. > > bye, > Sumit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Feb 19 00:28:24 2014 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 19 Feb 2014 00:28:24 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <558C15177F5E714F83334217C9A197DF014D126BFB@SSC-MBX1.ssc.internal> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com>, <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com>, <558C15177F5E714F83334217C9A197DF014D126BFB@SSC-MBX1.ssc.internal> Message-ID: <6b3e625595ee4f8eaa593a93ee18b43b@SINPR04MB298.apcprd04.prod.outlook.com> This is what I'd like to do, Linux users have nfs with samba for windows users. From what I can read however to get smba to work with AD I have to alter kerberos which is set to IPA...so I dont understand how you have it working. Currently Im trying to get samba just to work with a password set via smbpasswd but this is also failing, not sure if its a IPA interference issue or something else... regards Steven J ________________________________________ From: Johan Petersson Sent: Tuesday, 18 February 2014 8:18 p.m. To: Steven Jones; freeipa-users at redhat.com; dpal at redhat.com Subject: RE: [Freeipa-users] Setting up samba with IPA One solution that i have tested myself is to have IPA and AD sync with Samba as a server in a 2012 R2 Server AD. For shared directories used both by Windows and Linux clients like Home i used NFS 4 with Kerberos for Linux and Samba ADS for Windows. Same user could log in from both Windows and Linux with same password through winsync and passsync and get secured access with proper permissions on directories and files. Tested this setup out while i wait for IPA being able to handle all user accounts an resources in an IPA - AD trust. Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Tuesday, February 18, 2014 00:34 To: freeipa-users at redhat.com; dpal at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA Can we be clear here, Im not after SSO as such, I can sign in with the AD password but that is failing. Otherwise if I read you correctly I cant use IPA controlled samba with AD controlled windows hosts at all? So Im better to de-IPA samba and go back to the old samba method with a local password? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 18 February 2014 12:04 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA On 02/17/2014 05:49 PM, Steven Jones wrote: > Hi, > > So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? > > Ergo I have to remove IPA off the samba server? I think the setup when you have sync in place is a bit crafty. I know that people made it work in the past but with some assumptions that this is not an SSO. I mean you can't use a Window system and access Samba FS share when Samba FS is a member of IPA and IPA is in sync relations because user on Windows and user in IPA are two different users though they have same name Samba FS can't match the windows SID of the Windows user to the SID of the IPA user because there is no SID for IPA user. But on the other side I know that one can make Samba FS work with IPA, there have been articles about it. I am not sure what is the expectation about the clients in this case. The solution that we are working on is based on the trust. This part is not ready yet. Once ready Samba FS can be a member of the IPA domain, IPA would trust AD and then users from AD running Windows systems would be able to directly use Samba FS. This feature is in development right now. > regards > > Steven Jones > > ________________________________________ > From: Alexander Bokovoy > Sent: Tuesday, 18 February 2014 11:21 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On Mon, 17 Feb 2014, Steven Jones wrote: >> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >> enabled server OK. >> >> >> Is there a way to limit some users to CIFS only in IPA? > If you file system supports POSIX ACLs then simply set limits at the > file system level, it should work fine. > > http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html > >> Also however my AD connected windows7 machine with winsync and passsync >> in place to IPA wont connect. It doesnt seem to like the password....or >> user, unsure... > It doesn't like SID of that user and therefore doesn't think it is the > same user. There might be other reasons too, as we still haven't settled > down all bits to enable proper Windows integration for CIFS file > serving. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. From sbose at redhat.com Wed Feb 19 08:35:26 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 19 Feb 2014 09:35:26 +0100 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> Message-ID: <20140219083526.GD2781@localhost.localdomain> On Wed, Feb 19, 2014 at 12:17:59AM +0200, Genadi Postrilko wrote: > After i restarted SSSD nothing changed - still cannot login via ssh/su. > I have increased debug level to 6: > https://gist.github.com/anonymous/9081367 > (krb5_child was empty) The LDAP extented operation which should fetch the user data of the AD user fails: (Tue Feb 18 11:34:57 2014) [sssd[be[linux.adexample.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Tue Feb 18 11:34:57 2014) [sssd[be[linux.adexample.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) (Tue Feb 18 11:34:57 2014) [sssd[be[linux.adexample.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. hence the user is not available on the client and the login fails. Since winbind is working correctly on the server as shown by the wbinfo output below and the client is able to talk to the LDAP server in the IPA server I assume that there is an issue in processing the exop request or in the communication between the LDAP server and winbind. For the second you might want to check if there are any SELinux denials in your audit log. For the first you should enable debug logging for the LDAP server, see http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting for details. The log level which is needed here is 65536 'Plug-in debugging'. The logs might be too large for a mailing-list, fell free to send them to me directly. bye, Sumit > > Thank you. > > > > > 2014-02-18 11:38 GMT+02:00 Sumit Bose : > > > On Tue, Feb 18, 2014 at 01:11:38AM +0200, Genadi Postrilko wrote: > > > Thank you for the help! > > > I have preformed downgrade: > > > > > > yum downgrade samba4* > > > > > > [root at ipaserver1 ~]# rpm -qa | grep samb > > > samba4-python-4.0.0-58.el6.rc4.x86_64 > > > samba4-winbind-4.0.0-58.el6.rc4.x86_64 > > > samba4-common-4.0.0-58.el6.rc4.x86_64 > > > samba4-winbind-clients-4.0.0-58.el6.rc4.x86_64 > > > samba4-libs-4.0.0-58.el6.rc4.x86_64 > > > samba4-client-4.0.0-58.el6.rc4.x86_64 > > > samba4-4.0.0-58.el6.rc4.x86_64 > > > > > > And it worked ! > > > > > > *I am now able to perform login via "ssh" and su on to the ipaserver with > > > AD users:* > > > > > > [root at ipaserver1 ~]# su Genadi at ADEXAMPLE.COM > > > sh-4.1$ > > > > > > *and wbinfo and getent return values:* > > > > > > [root at ipaserver1 ~]# wbinfo -u > > > ADEXAMPLE\administrator > > > ADEXAMPLE\guest > > > ADEXAMPLE\genadi > > > ADEXAMPLE\krbtgt > > > ADEXAMPLE\linux$ > > > ADEXAMPLE\daniel > > > > > > [root at ipaserver1 ~]# wbinfo -g > > > admins > > > editors > > > default smb group > > > ad_users > > > ADEXAMPLE\domain computers > > > ADEXAMPLE\domain controllers > > > ADEXAMPLE\schema admins > > > ADEXAMPLE\enterprise admins > > > ADEXAMPLE\domain admins > > > ADEXAMPLE\domain users > > > ADEXAMPLE\domain guests > > > ADEXAMPLE\group policy creator owners > > > ADEXAMPLE\read-only domain controllers > > > ADEXAMPLE\enterprise read-only domain controllers > > > ADEXAMPLE\dnsupdateproxy > > > > > > [root at ipaserver1 ~]# getent passwd Genadi at ADEXAMPLE.COM > > > genadi at adexample.com:*:699001000:699001000::/home/adexample.com/genadi: > > > > Thanks a lot for confirming that -58 is working on the FreeIPA server. > > > > > > > > *After this success, i have tried to execute a login on client machine > > > (using AD user), but it did not work:* > > > > > > [root at ipaclient1 ~]# su Genadi at ADEXAMPLE.COM > > > su: user Genadi at ADEXAMPLE.COM does not exist > > > > > > *Also wbinfo and getent do not return value:* > > > > > > [root at ipaclient1 ~]# wbinfo -u > > > [root at ipaclient1 ~]# wbinfo -g > > > [root at ipaclient1 ~]# getent passwd Genadi at ADEXAMPLE.COM > > > > Winbind is not running on the IPA client. SSSD running on the IPA client > > use a LDAP extended operation to get the basic data about AD users and > > group. Please try to restart SSSD on the client. If this does not help, > > please send me the client's SSSD log files. > > > > bye, > > Sumit > > From barrykfl at gmail.com Wed Feb 19 09:37:42 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 19 Feb 2014 17:37:42 +0800 Subject: [Freeipa-users] Grey button in Reset password in the gui Message-ID: Dear all: I created a account of operator and added roles of user admin with reset /modify passwor priviges. but when he login , the reset password button is grey ? Any permission i should assign more... Now can only add this operator to admin group so all full access right. thks Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Feb 19 11:12:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Feb 2014 12:12:39 +0100 Subject: [Freeipa-users] Grey button in Reset password in the gui In-Reply-To: References: Message-ID: <530491A7.8050603@redhat.com> On 19.2.2014 10:37, barrykfl at gmail.com wrote: > Dear all: > > I created a account of operator and added roles of user admin with reset > /modify passwor priviges. > > but when he login , the reset password button is grey ? > > Any permission i should assign more... > > Now can only add this operator to admin group so all full access right. > > thks > > Barry > Hello, This link is enabled when logged in user has write permission for userpassword attribute. HTH -- Petr Vobornik From sigbjorn at nixtra.com Wed Feb 19 12:45:52 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 19 Feb 2014 13:45:52 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <5303B870.8030703@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> Message-ID: <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> On Tue, February 18, 2014 20:45, Rob Crittenden wrote: > Sigbjorn Lie wrote: > >>> On what machine are you trying to use the ipa tool? Is it one of the >>> masters, all of them, enrolled clients? >>> >> >> It's the same error message when the "ipa" command is run directly on any of the masters. >> >> >> And it's the same error message if I run the "ipa" command on any of the clients. >> >> >> I do not have a working "ipa" command anywhere anymore. >> > > Ok, let's test out the cert that ipa is using. Try this on any one of > the masters: > > $ curl https://`hostname`/ipa/xml > Should fail with Peer certificate cannot be authenticated with known CA > certificates Yes, this did not work: curl: (60) Peer certificate cannot be authenticated with known CA certificates More details here: http://curl.haxx.se/docs/sslcerts.html > > $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml > Should succeed in that you get the "you are not logged in" HTML page > Indeed - this works. > > Ok, now unfortunately curl only handles the sql-style NSS databases so > we can't fully reproduce it the same way that the IPA client is doing things, but here is an > approximation: > > > # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i > /etc/ipa/ca.crt > $ curl https://`hostname`/ipa/xml > You should see the login page HTML > Yes, I can now see the login page HTML. > > If you stick a -v in there it'll give you more verbose output which > would be useful if any of these fail in an unexpected way. > >>> Whatever is going on isn't likely related to the web server Apache >>> database as you get the same error out of each one. The client log you sent confirmed that it >>> tried to contact each master. The SSL error we're getting is that the client doesn't trust the >>> CA that >>> signed the server certificate so this appears to be a problem on the client, which begs the >>> question: all clients or just this one? >>> >>> >> >> All clients. >> >> >> >>> >>> NSS is smart enough to handle multiple certificates, it should pick the >>> newest one on startup. >>> >> >> Ok. >> >> >> Where do you suggest I continue troubleshooting this issue? >> > > We can also tackle this on the server side. Let's verify the server cert: > > > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias > This produces the same output for all 3 servers: certutil: certificate is valid > > This is verified on server startup so I expect it to be valid, but > doesn't hurt to try. > > Restarting the Apache process might be something to try as changes to > the NSS database aren't picked up until a restart. > I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt" on ipa03, and restarted httpd. The "ipa" command is now *working* on ipa03. :) However it's *not working* a client who's /etc/ipa/default.conf points at ipa03. Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? Regards, Siggi From pbrezina at redhat.com Wed Feb 19 13:48:33 2014 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 19 Feb 2014 14:48:33 +0100 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: References: <5301CC7D.6050903@redhat.com> <53033584.5050402@redhat.com> Message-ID: <5304B631.9080402@redhat.com> On 02/18/2014 10:32 PM, Steve Dainard wrote: > Hi Pavel, > > Very interesting, my IPA group membership in ad_admins isn't shown by > that command on first run (new login) > > sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin > uid=799002462(sdainard-admin at miovision.corp) > gid=799002462(sdainard-admin at miovision.corp) > groups=799002462(sdainard-admin at miovision.corp),799001380(accounting-share-access at miovision.corp),799001417(protected-share-access at miovision.corp),799000519(enterprise > admins at miovision.corp),799001416(hr-share-access at miovision.corp),799000512(domain > admins at miovision.corp),799000513(domain > users at miovision.corp),799002464(it - > admins at miovision.corp),799002469(kloperators at miovision.corp),799002468(kladmins at miovision.corp) > > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > > But after attempting the sudo command my groups do contain the IPA > groups admins,ad_admins: > > sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin > uid=799002462(sdainard-admin at miovision.corp) > gid=799002462(sdainard-admin at miovision.corp) > groups=799002462(sdainard-admin at miovision.corp),799001380(accounting-share-access at miovision.corp),799001417(protected-share-access at miovision.corp),799000519(enterprise > admins at miovision.corp),799001416(hr-share-access at miovision.corp),799000512(domain > admins at miovision.corp),799000513(domain > users at miovision.corp),799002464(it - > admins at miovision.corp),799002469(kloperators at miovision.corp),799002468(kladmins at miovision.corp),*1768200000(admins),1768200004(ad_admins)* > > sdainard-admin at miovision.corp@ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.corp/sdainard-admin# > > > Sudo rule (I had to create this, apparently its a default rule, but > didn't exist in my install on RHEL7 beta): > Rule name: All > Enabled: TRUE > Host category: all > Command category: all > RunAs User category: all > RunAs Group category: all > User Groups: ad_admins Can you tell me more information about admins and ad_admins groups and sdainard-admin? I would like to know how the membership is configured and what is their relation to AD. Dump of ipa user-show and ipa group-show should be enough, I think. > > I saw the new dns update option (and refresh timers!), thanks. > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------------------------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. > If you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Tue, Feb 18, 2014 at 5:27 AM, Pavel B?ezina > wrote: > > On 02/17/2014 10:29 PM, Steve Dainard wrote: > > I can't reproduce consistently on any OS including Fedora 20, > but I was > able to trigger the issue on a Ubuntu 13.10 client. > > sssd: 1.11.1 > > sudo: 1.8.6p3-0ubuntu3 > > I have only just enabled the sudo logging so it should only > contain the > events below: > > sdainard-admin at miovision.corp@__ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > sdainard-admin at miovision.corp@__ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.__corp/sdainard-admin# > > Files attached outside of list. > > > Hi, > thank you for the logs. Can you also send me output of command "id > sdainard-admin" (also check if group membership is correct) and > definition of the sudo rule please? > > Also you may want to fix the following (unrelated) warning: > Deprecation warning: The option ipa_dyndns_update is deprecated and > should not be used in favor of dyndns_update > > From jpazdziora at redhat.com Wed Feb 19 14:24:44 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 19 Feb 2014 15:24:44 +0100 Subject: [Freeipa-users] HBAC - expected behaviour? In-Reply-To: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226062946@AACMBXP04.exchserver.com> Message-ID: <20140219142443.GO14633@redhat.com> On Tue, Feb 04, 2014 at 04:11:12AM +0000, Les Stott wrote: > > If I access the host "host1" and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). I can see you've found the solution already but I'd like to go back to this part. You say that you have removed allow_all from its defined HBAC ruls in the WebUI. However, when I try this on my FreeIPA server, I don't see allow_all listed for any of my hosts (neither in the Direct nor Indirect Membership listing). Is it possible that you've added that host to allow_all on top of its "Any Host" (aka Host category: all) manually and then removed it? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From sdainard at miovision.com Wed Feb 19 14:27:21 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 19 Feb 2014 09:27:21 -0500 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: <5304B631.9080402@redhat.com> References: <5301CC7D.6050903@redhat.com> <53033584.5050402@redhat.com> <5304B631.9080402@redhat.com> Message-ID: Hi Pavel, sdainard-admin is a Windows domain user, part of an external group 'ad_admins_external' which is a member of 'ad_admins', an ipa posix group. 'admins' groups is the built-in ipa admin group. ipa group-show admins Group name: admins Description: Account administrators group GID: 1768200000 Member users: admin Member groups: ad_admins Member of Sudo rule: ad_admins Indirect Member groups: ad_admins_external ipa group-show ad_admins Group name: ad_admins Description: miovision.corp admins GID: 1768200004 Member users: admin Member groups: ad_admins_external Member of groups: admins Member of Sudo rule: ad_admins, All Thanks, *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 19, 2014 at 8:48 AM, Pavel B?ezina wrote: > On 02/18/2014 10:32 PM, Steve Dainard wrote: > >> Hi Pavel, >> >> Very interesting, my IPA group membership in ad_admins isn't shown by >> that command on first run (new login) >> >> sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin >> uid=799002462(sdainard-admin at miovision.corp) >> gid=799002462(sdainard-admin at miovision.corp) >> groups=799002462(sdainard-admin at miovision.corp), >> 799001380(accounting-share-access at miovision.corp), >> 799001417(protected-share-access at miovision.corp),799000519(enterprise >> admins at miovision.corp),799001416(hr-share-access@ >> miovision.corp),799000512(domain >> admins at miovision.corp),799000513(domain >> users at miovision.corp),799002464(it - >> admins at miovision.corp),799002469(kloperators at miovision.corp),799002468( >> kladmins at miovision.corp) >> >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. >> This incident will be reported. >> >> But after attempting the sudo command my groups do contain the IPA >> groups admins,ad_admins: >> >> sdainard-admin at miovision.corp@ubu1310:~$ id sdainard-admin >> uid=799002462(sdainard-admin at miovision.corp) >> gid=799002462(sdainard-admin at miovision.corp) >> groups=799002462(sdainard-admin at miovision.corp), >> 799001380(accounting-share-access at miovision.corp), >> 799001417(protected-share-access at miovision.corp),799000519(enterprise >> admins at miovision.corp),799001416(hr-share-access@ >> miovision.corp),799000512(domain >> admins at miovision.corp),799000513(domain >> users at miovision.corp),799002464(it - >> admins at miovision.corp),799002469(kloperators at miovision.corp),799002468( >> kladmins at miovision.corp),*1768200000(admins),1768200004(ad_admins)* >> >> >> sdainard-admin at miovision.corp@ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> root at ubu1310:/home/miovision.corp/sdainard-admin# >> >> >> Sudo rule (I had to create this, apparently its a default rule, but >> didn't exist in my install on RHEL7 beta): >> Rule name: All >> Enabled: TRUE >> Host category: all >> Command category: all >> RunAs User category: all >> RunAs Group category: all >> User Groups: ad_admins >> > > Can you tell me more information about admins and ad_admins groups and > sdainard-admin? I would like to know how the membership is configured and > what is their relation to AD. Dump of ipa user-show and ipa group-show > should be enough, I think. > > >> I saw the new dns update option (and refresh timers!), thanks. >> >> *Steve Dainard * >> IT Infrastructure Manager >> Miovision | /Rethink Traffic/ >> >> *Blog | **LinkedIn >> | Twitter >> | Facebook >> * >> ------------------------------------------------------------------------ >> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, >> ON, Canada | N2C 1L3 >> This e-mail may contain information that is privileged or confidential. >> If you are not the intended recipient, please delete the e-mail and any >> attachments and notify us immediately. >> >> >> On Tue, Feb 18, 2014 at 5:27 AM, Pavel B?ezina > > wrote: >> >> On 02/17/2014 10:29 PM, Steve Dainard wrote: >> >> I can't reproduce consistently on any OS including Fedora 20, >> but I was >> able to trigger the issue on a Ubuntu 13.10 client. >> >> sssd: 1.11.1 >> >> sudo: 1.8.6p3-0ubuntu3 >> >> I have only just enabled the sudo logging so it should only >> contain the >> events below: >> >> sdainard-admin at miovision.corp@__ubu1310:~$ sudo su >> >> [sudo] password for sdainard-admin at miovision.corp: >> sdainard-admin at miovision.corp is not allowed to run sudo on >> ubu1310. >> This incident will be reported. >> sdainard-admin at miovision.corp@__ubu1310:~$ sudo su >> [sudo] password for sdainard-admin at miovision.corp: >> root at ubu1310:/home/miovision.__corp/sdainard-admin# >> >> >> Files attached outside of list. >> >> >> Hi, >> thank you for the logs. Can you also send me output of command "id >> sdainard-admin" (also check if group membership is correct) and >> definition of the sudo rule please? >> >> Also you may want to fix the following (unrelated) warning: >> Deprecation warning: The option ipa_dyndns_update is deprecated and >> should not be used in favor of dyndns_update >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Suhail.Choudhury at bskyb.com Wed Feb 19 15:33:02 2014 From: Suhail.Choudhury at bskyb.com (Choudhury, Suhail) Date: Wed, 19 Feb 2014 15:33:02 +0000 Subject: [Freeipa-users] Export data In-Reply-To: <52DFC812.4090907@redhat.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com>, <52DFC812.4090907@redhat.com> Message-ID: <9769CCE57C8E5A44B968BAB6618511339653C4@WPMBX060.bskyb.com> Hi Martin, Thanks for your previous answer. And how can I export a list of DNS entries using ldapsearch? Regards, Suhail. DevOps BSkyB. ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: 22 January 2014 13:30 To: Choudhury, Suhail; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Export data On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: > Hi guys, > > I trying to get a dump of all users, hosts and DNS entries from IPA so > we can run scripts/Puppet against them. > > Tried searching for it but cannot find anything, so was hoping someone > can give some hints on how best to do this please. > You can either export them via ldapsearch: $ kinit admin $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' ... or for write a Python script to do what you want. Very simple example: $ kinit admin $ python >>> from ipalib import api >>> api.bootstrap() >>> api.finalize() >>> api.Backend.xmlclient.connect() >>> users = api.Command.user_find() >>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], user['uidnumber'][0], user['gidnumber'][0]) ... admin:1913600000:1913600000 tuser:1913600001:1913600001 Martin Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From mkosek at redhat.com Wed Feb 19 15:48:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Feb 2014 16:48:50 +0100 Subject: [Freeipa-users] Export data In-Reply-To: <9769CCE57C8E5A44B968BAB6618511339653C4@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com>, <52DFC812.4090907@redhat.com> <9769CCE57C8E5A44B968BAB6618511339653C4@WPMBX060.bskyb.com> Message-ID: <5304D262.8090206@redhat.com> Similarly to users, you just use the right container: $ kinit admin $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=dns,dc=example,dc=com' There are plenty of resources online how to work with ldapsearch, ldapmodify and resulting LDIFs that could help get you started. Martin On 02/19/2014 04:33 PM, Choudhury, Suhail wrote: > Hi Martin, > > Thanks for your previous answer. > > And how can I export a list of DNS entries using ldapsearch? > > Regards, > Suhail. > DevOps BSkyB. > > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: 22 January 2014 13:30 > To: Choudhury, Suhail; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Export data > > On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: >> Hi guys, >> >> I trying to get a dump of all users, hosts and DNS entries from IPA so >> we can run scripts/Puppet against them. >> >> Tried searching for it but cannot find anything, so was hoping someone >> can give some hints on how best to do this please. >> > > You can either export them via ldapsearch: > > $ kinit admin > $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' > > > ... or for write a Python script to do what you want. Very simple example: > > $ kinit admin > $ python >>>> from ipalib import api >>>> api.bootstrap() >>>> api.finalize() >>>> api.Backend.xmlclient.connect() >>>> users = api.Command.user_find() >>>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], > user['uidnumber'][0], user['gidnumber'][0]) > ... > admin:1913600000:1913600000 > tuser:1913600001:1913600001 > > > Martin > > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this! paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > > From raubvogel at gmail.com Wed Feb 19 17:51:30 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Wed, 19 Feb 2014 12:51:30 -0500 Subject: [Freeipa-users] Windows client Message-ID: When I added a windows 7 client (let's call it windows.lan.domain.com), I had to go manually enter the domain (in System Properties->Computer Name/Domain Changes->DNS Suffix and netbios computer name) even though ipconfig would report it properly. Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I know the realm and the domain names are not quite the same (domain has a "lan" in it), but should that matter? On an unrelated note, in http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it should be ksetup /addkpasswd not ksetup /addkpassword From shreerajkarulkar at yahoo.com Wed Feb 19 18:07:23 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 19 Feb 2014 10:07:23 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FB349B.6020901@redhat.com> <1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com> <52FBBE2E.9020904@redhat.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> Message-ID: <1392833243.68068.YahooMailNeo@web160101.mail.bf1.yahoo.com> Guys Any word on this? New logs are attached to the email. I am still not able to add clients using the replica. Let me know if you need any other information and thanks for you help. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Tuesday, February 18, 2014 1:18 PM, Shree wrote: 1) I have got a step furthur. My replica is not running CA Service. To achieve this I had to remove the existing cert with this command pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force Now the replica looks like this skarulkar at ldap2 tmp]$ sudo ipactl status [sudo] password for skarulkar: Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [skarulkar at ldap2 tmp]$ 2) I am still not able to add client using ipa-client-install using the replica. Logs for replica install and client install are attached. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Tuesday, February 18, 2014 11:31 AM, Shree wrote: Rob The logs are attached in the email chain. If you need fresh ones, I can try to replicate it again. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Tuesday, February 18, 2014 11:19 AM, Rob Crittenden wrote: Shree wrote: > Rob > I am giving it a fresh start and I notice similar issues. > > 1) I wasn't able to use the "--setup-ca" while running the > ipa-replica-install on the replica. It stopped the install after the > ntpd step see below. > > Done configuring NTP daemon (ntpd). > A CA is already configured on this system. This is left over from a previous failed installation. If the CA install fails early enough we don't log the fact that it was installed so the uninstall doesn't clean it up. > 2) So I tried my install command again without the --setup-ca option. It > went furthur although it completed it show one error see below. > >? MY COMMAND: --> ipa-replica-install > /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck > the skip-conncheck was needed to complete the install. Connections > checks were manually done. > 14/31]: configuring lockout plugin >? ? [15/31]: creating indices >? ? [16/31]: enabling referential integrity plugin >? ? [17/31]: configuring ssl for ds instance > ipa? ? ? ? : ERROR? ? certmonger failed starting to track certificate: > Command '/usr/bin/ipa-getcert start-tracking -d > /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p > /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C > /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero > exit status 1 >? ? [18/31]: configuring certmap.conf >? ? [19/31]: configure autobind for root > ......................................... Without logs there is no way to diagnose. This could leave you in a situation where the certificate fails to renew in 2 years and IPA suddenly stops working. > 3) The replica installed fine I can access the same database from the > replica's website. > > 4) I cannot add new clients. > MY COMMAND: --> ipa-client-install --domain=mydomain.com > --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d > > ldap.mydomain.com = master > ldap2.mydomain.com = replica No idea without seeing the logs. rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Feb 19 18:34:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Feb 2014 20:34:13 +0200 Subject: [Freeipa-users] Windows client In-Reply-To: References: Message-ID: <20140219183413.GB16644@redhat.com> On Wed, 19 Feb 2014, Mauricio Tavares wrote: > When I added a windows 7 client (let's call it >windows.lan.domain.com), I had to go manually enter the domain (in >System Properties->Computer Name/Domain Changes->DNS Suffix and >netbios computer name) even though ipconfig would report it properly. >Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM >instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I >know the realm and the domain names are not quite the same (domain has >a "lan" in it), but should that matter? Windows uses NetBIOS name$ as the machine name in TGT requests for the host. At this point we don't have means to correct this via IPA CLI. You need to use ldapmodify directly and add krbprincipalname: windows$DOMAIN.COM krbcanonicalname: HOST/windows.lan.domain.com at DOMAIN.COM to the host entry. KrbPrincipalName can have multiple values and if there are more than one, KrbCanonicalName should be set to the canonical version which is the original KrbPrincipalName in IPA. > On an unrelated note, in >http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it >should be > >ksetup /addkpasswd > >not > >ksetup /addkpassword Corrected, thanks! -- / Alexander Bokovoy From simo at redhat.com Wed Feb 19 18:44:08 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Feb 2014 13:44:08 -0500 Subject: [Freeipa-users] Windows client In-Reply-To: <20140219183413.GB16644@redhat.com> References: <20140219183413.GB16644@redhat.com> Message-ID: <1392835448.22754.163.camel@willson.li.ssimo.org> On Wed, 2014-02-19 at 20:34 +0200, Alexander Bokovoy wrote: > On Wed, 19 Feb 2014, Mauricio Tavares wrote: > > When I added a windows 7 client (let's call it > >windows.lan.domain.com), I had to go manually enter the domain (in > >System Properties->Computer Name/Domain Changes->DNS Suffix and > >netbios computer name) even though ipconfig would report it properly. > >Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM > >instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I > >know the realm and the domain names are not quite the same (domain has > >a "lan" in it), but should that matter? > Windows uses NetBIOS name$ as the machine name in TGT requests for the > host. > > At this point we don't have means to correct this via IPA CLI. You need > to use ldapmodify directly and add > > krbprincipalname: windows$DOMAIN.COM > krbcanonicalname: HOST/windows.lan.domain.com at DOMAIN.COM Note that 'host' here should be lower case. Simo. > to the host entry. > > KrbPrincipalName can have multiple values and if there are more than > one, KrbCanonicalName should be set to the canonical version which is > the original KrbPrincipalName in IPA. > > > > On an unrelated note, in > >http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it > >should be > > > >ksetup /addkpasswd > > > >not > > > >ksetup /addkpassword > Corrected, thanks! > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Feb 19 19:02:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 20:02:24 +0100 Subject: [Freeipa-users] Windows client In-Reply-To: <1392835448.22754.163.camel@willson.li.ssimo.org> References: <20140219183413.GB16644@redhat.com> <1392835448.22754.163.camel@willson.li.ssimo.org> Message-ID: <5304FFC0.30202@redhat.com> On 19.2.2014 19:44, Simo Sorce wrote: > On Wed, 2014-02-19 at 20:34 +0200, Alexander Bokovoy wrote: >> On Wed, 19 Feb 2014, Mauricio Tavares wrote: >>> When I added a windows 7 client (let's call it >>> windows.lan.domain.com), I had to go manually enter the domain (in >>> System Properties->Computer Name/Domain Changes->DNS Suffix and >>> netbios computer name) even though ipconfig would report it properly. >>> Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM >>> instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I >>> know the realm and the domain names are not quite the same (domain has >>> a "lan" in it), but should that matter? >> Windows uses NetBIOS name$ as the machine name in TGT requests for the >> host. >> >> At this point we don't have means to correct this via IPA CLI. You need >> to use ldapmodify directly and add >> >> krbprincipalname: windows$DOMAIN.COM >> krbcanonicalname: HOST/windows.lan.domain.com at DOMAIN.COM > > Note that 'host' here should be lower case. ... And please note that http://www.freeipa.org/page/Windows_authentication_against_FreeIPA is an option of last resort. Please use real trust between AD and IPA whenever possible: http://www.freeipa.org/page/Trusts Have a nice day! Petr^2 Spacek >> to the host entry. >> >> KrbPrincipalName can have multiple values and if there are more than >> one, KrbCanonicalName should be set to the canonical version which is >> the original KrbPrincipalName in IPA. >> >> >>> On an unrelated note, in >>> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it >>> should be >>> >>> ksetup /addkpasswd >>> >>> not >>> >>> ksetup /addkpassword >> Corrected, thanks! From raubvogel at gmail.com Wed Feb 19 19:10:01 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Wed, 19 Feb 2014 14:10:01 -0500 Subject: [Freeipa-users] Windows client In-Reply-To: <5304FFC0.30202@redhat.com> References: <20140219183413.GB16644@redhat.com> <1392835448.22754.163.camel@willson.li.ssimo.org> <5304FFC0.30202@redhat.com> Message-ID: On Wed, Feb 19, 2014 at 2:02 PM, Petr Spacek wrote: > On 19.2.2014 19:44, Simo Sorce wrote: >> >> On Wed, 2014-02-19 at 20:34 +0200, Alexander Bokovoy wrote: >>> >>> On Wed, 19 Feb 2014, Mauricio Tavares wrote: >>>> >>>> When I added a windows 7 client (let's call it >>>> windows.lan.domain.com), I had to go manually enter the domain (in >>>> System Properties->Computer Name/Domain Changes->DNS Suffix and >>>> netbios computer name) even though ipconfig would report it properly. >>>> Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM >>>> instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I >>>> know the realm and the domain names are not quite the same (domain has >>>> a "lan" in it), but should that matter? >>> >>> Windows uses NetBIOS name$ as the machine name in TGT requests for the >>> host. >>> >>> At this point we don't have means to correct this via IPA CLI. You need >>> to use ldapmodify directly and add >>> >>> krbprincipalname: windows$DOMAIN.COM >>> krbcanonicalname: HOST/windows.lan.domain.com at DOMAIN.COM >> >> >> Note that 'host' here should be lower case. > > > ... And please note that > http://www.freeipa.org/page/Windows_authentication_against_FreeIPA is an > option of last resort. > > Please use real trust between AD and IPA whenever possible: > http://www.freeipa.org/page/Trusts > Would not having an AD server be eligible for the option of last resort? > Have a nice day! > > Petr^2 Spacek > > >>> to the host entry. >>> >>> KrbPrincipalName can have multiple values and if there are more than >>> one, KrbCanonicalName should be set to the canonical version which is >>> the original KrbPrincipalName in IPA. >>> >>> >>>> On an unrelated note, in >>>> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it >>>> should be >>>> >>>> ksetup /addkpasswd >>>> >>>> not >>>> >>>> ksetup /addkpassword >>> >>> Corrected, thanks! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From shreerajkarulkar at yahoo.com Wed Feb 19 19:47:54 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 19 Feb 2014 11:47:54 -0800 (PST) Subject: [Freeipa-users] Unexpected error at the end of ipa-replica-install Message-ID: <1392839274.26668.YahooMailNeo@web160104.mail.bf1.yahoo.com> Everything seems to be going well for all the 17 of 17 steps and then this ?[15/17]: configure clone certificate renewals ? [16/17]: configure Server-Cert certificate renewal ? [17/17]: Configure HTTP to proxy connections Done configuring certificate server (pki-cad). Restarting the directory and certificate servers Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: CalledProcessError: Command '/sbin/service pki-cad stop pki-ca' returned non-zero exit status 4 [root at ldap3 ~]# ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Feb 19 19:48:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 19 Feb 2014 20:48:04 +0100 Subject: [Freeipa-users] Windows client In-Reply-To: References: <20140219183413.GB16644@redhat.com> <1392835448.22754.163.camel@willson.li.ssimo.org> <5304FFC0.30202@redhat.com> Message-ID: <53050A74.1080907@redhat.com> On 19.2.2014 20:10, Mauricio Tavares wrote: > On Wed, Feb 19, 2014 at 2:02 PM, Petr Spacek wrote: >> On 19.2.2014 19:44, Simo Sorce wrote: >>> >>> On Wed, 2014-02-19 at 20:34 +0200, Alexander Bokovoy wrote: >>>> >>>> On Wed, 19 Feb 2014, Mauricio Tavares wrote: >>>>> >>>>> When I added a windows 7 client (let's call it >>>>> windows.lan.domain.com), I had to go manually enter the domain (in >>>>> System Properties->Computer Name/Domain Changes->DNS Suffix and >>>>> netbios computer name) even though ipconfig would report it properly. >>>>> Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM >>>>> instead of windows.lan.domain.com at DOMAIN.COM. Does anyone know why? I >>>>> know the realm and the domain names are not quite the same (domain has >>>>> a "lan" in it), but should that matter? >>>> >>>> Windows uses NetBIOS name$ as the machine name in TGT requests for the >>>> host. >>>> >>>> At this point we don't have means to correct this via IPA CLI. You need >>>> to use ldapmodify directly and add >>>> >>>> krbprincipalname: windows$DOMAIN.COM >>>> krbcanonicalname: HOST/windows.lan.domain.com at DOMAIN.COM >>> >>> >>> Note that 'host' here should be lower case. >> >> >> ... And please note that >> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA is an >> option of last resort. >> >> Please use real trust between AD and IPA whenever possible: >> http://www.freeipa.org/page/Trusts >> > Would not having an AD server be eligible for the option of last resort? Sure, when Samba 4 has an ability to create trust with IPA :-) Seriously, if you have non-trivial network with Windows clients you really need something for managing them - most likely AD or Samba 4. Unfortunately, Samba 4 is not able to create trust with IPA right now. Petr^2 Spacek >>>> to the host entry. >>>> >>>> KrbPrincipalName can have multiple values and if there are more than >>>> one, KrbCanonicalName should be set to the canonical version which is >>>> the original KrbPrincipalName in IPA. >>>> >>>> >>>>> On an unrelated note, in >>>>> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it >>>>> should be >>>>> >>>>> ksetup /addkpasswd >>>>> >>>>> not >>>>> >>>>> ksetup /addkpassword >>>> >>>> Corrected, thanks! -- Petr^2 Spacek From rcritten at redhat.com Wed Feb 19 20:59:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Feb 2014 15:59:30 -0500 Subject: [Freeipa-users] Export data In-Reply-To: <9769CCE57C8E5A44B968BAB6618511339653C4@WPMBX060.bskyb.com> References: <9769CCE57C8E5A44B968BAB66185113394E556@WPMBX060.bskyb.com>, <52DFC812.4090907@redhat.com> <9769CCE57C8E5A44B968BAB6618511339653C4@WPMBX060.bskyb.com> Message-ID: <53051B32.8030209@redhat.com> Choudhury, Suhail wrote: > Hi Martin, > > Thanks for your previous answer. > > And how can I export a list of DNS entries using ldapsearch? He included the basics in his previous answer: > $ kinit admin > $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' You can append the command with the list of attributes you want, and suppress a bunch of the extraneous output with -LLL, so something like: $ ldapsearch -LLL -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' dn rob > > Regards, > Suhail. > DevOps BSkyB. > > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: 22 January 2014 13:30 > To: Choudhury, Suhail; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Export data > > On 01/22/2014 01:48 PM, Choudhury, Suhail wrote: >> Hi guys, >> >> I trying to get a dump of all users, hosts and DNS entries from IPA so >> we can run scripts/Puppet against them. >> >> Tried searching for it but cannot find anything, so was hoping someone >> can give some hints on how best to do this please. >> > > You can either export them via ldapsearch: > > $ kinit admin > $ ldapsearch -h `hostname` -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' > > > ... or for write a Python script to do what you want. Very simple example: > > $ kinit admin > $ python >>>> from ipalib import api >>>> api.bootstrap() >>>> api.finalize() >>>> api.Backend.xmlclient.connect() >>>> users = api.Command.user_find() >>>> for user in users['result']:... print "%s:%s:%s" % (user['uid'][0], > user['uidnumber'][0], user['gidnumber'][0]) > ... > admin:1913600000:1913600000 > tuser:1913600001:1913600001 > > > Martin > > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this! p! > aragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Wed Feb 19 20:59:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Feb 2014 15:59:33 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> Message-ID: <53051B35.2050409@redhat.com> Shree wrote: > 1) I have got a step furthur. My replica is not running CA Service. To > achieve this I had to remove the existing cert with this command > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > Now the replica looks like this > > skarulkar at ldap2 tmp]$ sudo ipactl status > [sudo] password for skarulkar: > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [skarulkar at ldap2 tmp]$ The tracking failed with: 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: Improper format of Kerberos configuration file. It looks like it failed on this for most if not all the tracking. What does /etc/krb5.conf look like? > > 2) I am still not able to add client using ipa-client-install using the > replica. The temporary krb5.conf that is used during enrollment has dns_lookup_kdc=True so it is probably trying to contact the other KDC and failing. What is the output of: $ rpm -q ipa-client rob From shreerajkarulkar at yahoo.com Wed Feb 19 21:09:12 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 19 Feb 2014 13:09:12 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <53051B35.2050409@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBC071.3050602@redhat.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> Message-ID: <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com> Here are a couple of things [skarulkar at ldap2 ~]$ rpm -q ipa-client ipa-client-3.0.0-26.el6_4.4.x86_64 and my /etc/krb5.conf looks like .......... ======================================= 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 = ldap2.mydomain.com:88 ? master_kdc = ldap2.mydomain.com:88 ? admin_server = ldap2.mydomain.com:749 ? default_domain = mydomain.com ? pkinit_anchors = FILE:/etc/ipa/ca.crt 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 ? } ======================================= ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden wrote: Shree wrote: > 1) I have got a step furthur. My replica is not running CA Service. To > achieve this I had to remove the existing cert with this command > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > Now the replica looks like this > > skarulkar at ldap2 tmp]$ sudo ipactl status > [sudo] password for skarulkar: > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [skarulkar at ldap2 tmp]$ The tracking failed with: 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: Improper format of Kerberos configuration file. It looks like it failed on this for most if not all the tracking. What does /etc/krb5.conf look like? > > 2) I am still not able to add client using ipa-client-install using the > replica. The temporary krb5.conf that is used during enrollment has dns_lookup_kdc=True so it is probably trying to contact the other KDC and failing. What is the output of: $ rpm -q ipa-client rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 19 21:17:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Feb 2014 16:17:22 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com> Message-ID: <53051F62.40405@redhat.com> Shree wrote: > Here are a couple of things > > [skarulkar at ldap2 ~]$ rpm -q ipa-client > ipa-client-3.0.0-26.el6_4.4.x86_64 What is the version on the client that is failing to enroll? rob > > and my /etc/krb5.conf looks like .......... > ======================================= > 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 = ldap2.mydomain.com:88 > master_kdc = ldap2.mydomain.com:88 > admin_server = ldap2.mydomain.com:749 > default_domain = mydomain.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > 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 > } > > ======================================= > > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden > wrote: > Shree wrote: > > 1) I have got a step furthur. My replica is not running CA Service. To > > achieve this I had to remove the existing cert with this command > > > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > > > Now the replica looks like this > > > > skarulkar at ldap2 tmp]$ sudo ipactl status > > [sudo] password for skarulkar: > > Directory Service: RUNNING > > KDC Service: RUNNING > > KPASSWD Service: RUNNING > > MEMCACHE Service: RUNNING > > HTTP Service: RUNNING > > CA Service: RUNNING > > [skarulkar at ldap2 tmp]$ > > The tracking failed with: > > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: > Improper format of Kerberos configuration file. > > It looks like it failed on this for most if not all the tracking. What > does /etc/krb5.conf look like? > > > > > 2) I am still not able to add client using ipa-client-install using the > > replica. > > The temporary krb5.conf that is used during enrollment has > dns_lookup_kdc=True so it is probably trying to contact the other KDC > and failing. > > What is the output of: > > $ rpm -q ipa-client > > > rob > > > From shreerajkarulkar at yahoo.com Wed Feb 19 21:51:21 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 19 Feb 2014 13:51:21 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <53051F62.40405@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52FBCD8E.8060705@redhat.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> Message-ID: <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com> root at test500 ~]# rpm -q ipa-client ipa-client-2.2.0-16.el6.x86_64 [root at test500 ~]# ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden wrote: Shree wrote: > Here are a couple of things > > [skarulkar at ldap2 ~]$ rpm -q ipa-client > ipa-client-3.0.0-26.el6_4.4.x86_64 What is the version on the client that is failing to enroll? rob > > and my /etc/krb5.conf looks like .......... > ======================================= > 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 = ldap2.mydomain.com:88 >? ? master_kdc = ldap2.mydomain.com:88 >? ? admin_server = ldap2.mydomain.com:749 >? ? default_domain = mydomain.com >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt > 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 >? ? } > > ======================================= > > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden > wrote: > Shree wrote: >? > 1) I have got a step furthur. My replica is not running CA Service. To >? > achieve this I had to remove the existing cert with this command >? > >? > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >? > >? > Now the replica looks like this >? > >? > skarulkar at ldap2 tmp]$ sudo ipactl status >? > [sudo] password for skarulkar: >? > Directory Service: RUNNING >? > KDC Service: RUNNING >? > KPASSWD Service: RUNNING >? > MEMCACHE Service: RUNNING >? > HTTP Service: RUNNING >? > CA Service: RUNNING >? > [skarulkar at ldap2 tmp]$ > > The tracking failed with: > > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: > Improper format of Kerberos configuration file. > > It looks like it failed on this for most if not all the tracking. What > does /etc/krb5.conf look like? > >? > >? > 2) I am still not able to add client using ipa-client-install using the >? > replica. > > The temporary krb5.conf that is used during enrollment has > dns_lookup_kdc=True so it is probably trying to contact the other KDC > and failing. > > What is the output of: > > $ rpm -q ipa-client > > > rob > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 19 22:21:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Feb 2014 17:21:24 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com> Message-ID: <53052E64.3050903@redhat.com> Shree wrote: > root at test500 ~]# rpm -q ipa-client > ipa-client-2.2.0-16.el6.x86_64 > [root at test500 ~]# You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 Unfortunately our logging around discovery was rather horrible in 2.2.x so it is difficult to know exactly what is going on. I believe the problem is that it is still doing DNS discovery even though you've passed in a server name so it is setting up Kerberos to look up the KDC which it finds but can't talk to. This should be fixed in the 3.0 packages so updating to those is the preferred solution. For 2.x you can try the --force option which should make it skip some discovery. rob > > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden > wrote: > Shree wrote: > > Here are a couple of things > > > > [skarulkar at ldap2 ~]$ rpm -q ipa-client > > ipa-client-3.0.0-26.el6_4.4.x86_64 > > What is the version on the client that is failing to enroll? > > rob > > > > > and my /etc/krb5.conf looks like .......... > > ======================================= > > 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 = ldap2.mydomain.com:88 > > master_kdc = ldap2.mydomain.com:88 > > admin_server = ldap2.mydomain.com:749 > > default_domain = mydomain.com > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > 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 > > } > > > > ======================================= > > > > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden > > > wrote: > > Shree wrote: > > > 1) I have got a step furthur. My replica is not running CA Service. To > > > achieve this I had to remove the existing cert with this command > > > > > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force > > > > > > Now the replica looks like this > > > > > > skarulkar at ldap2 > tmp]$ sudo ipactl status > > > [sudo] password for skarulkar: > > > Directory Service: RUNNING > > > KDC Service: RUNNING > > > KPASSWD Service: RUNNING > > > MEMCACHE Service: RUNNING > > > HTTP Service: RUNNING > > > CA Service: RUNNING > > > [skarulkar at ldap2 > tmp]$ > > > > > The tracking failed with: > > > > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: > > Improper format of Kerberos configuration file. > > > > It looks like it failed on this for most if not all the tracking. What > > does /etc/krb5.conf look like? > > > > > > > > 2) I am still not able to add client using ipa-client-install > using the > > > replica. > > > > The temporary krb5.conf that is used during enrollment has > > dns_lookup_kdc=True so it is probably trying to contact the other KDC > > and failing. > > > > What is the output of: > > > > $ rpm -q ipa-client > > > > > > rob > > > > > > > > > From dpal at redhat.com Wed Feb 19 22:23:15 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 19 Feb 2014 17:23:15 -0500 Subject: [Freeipa-users] About Windows client Message-ID: <53052ED3.3030906@redhat.com> Hello, I want to summarize our position regarding joining Windows systems into IPA. 1) If you already have AD we recommend using this system with AD and using trusts between AD and IPA. 2) If you do not have AD then use Samba 4 instead of it. It would be great when Samba 4 grows capability to establish trusts. Right now it can't but there is an effort going on. If you are interested - please contribute. 3) If neither of the two options work for you you can configure Windows system to work directly with IPA as described on the wiki. It is an option of last resort because IPA does not provide the services windows client expects. If this is good enough for you, fine by us. 4) Build a native Windows client (cred provider) for IPA using latest Kerberos. IMO this would be really useful if someone does that because we will not build this ourselves. With the native OTP support in IPA it becomes a real business opportunity to provide a native 2FA inside enterprise across multiple platforms. But please do it open source way otherwise we would not recommend you ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shreerajkarulkar at yahoo.com Wed Feb 19 23:52:23 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Wed, 19 Feb 2014 15:52:23 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <53052E64.3050903@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBDCD8.2080800@redhat.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> Message-ID: <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.com> Rob You were right. After upgrading the client to the ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning during the client install that went something like ================= Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: yes ================= I continued by saying yes because in my case the master and the replica are in different VLANs and failover is not possible for me. I have tried in two hosts successfully and am hoping that does the trick. However I see one issue immediately that my sudo access does not seem to work now on the newly added clients! Do you know what might be happening? ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden wrote: Shree wrote: > root at test500 ~]# rpm -q ipa-client > ipa-client-2.2.0-16.el6.x86_64 > [root at test500 ~]# You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 Unfortunately our logging around discovery was rather horrible in 2.2.x so it is difficult to know exactly what is going on. I believe the problem is that it is still doing DNS discovery even though you've passed in a server name so it is setting up Kerberos to look up the KDC which it finds but can't talk to. This should be fixed in the 3.0 packages so updating to those is the preferred solution. For 2.x you can try the --force option which should make it skip some discovery. rob > > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden > wrote: > Shree wrote: >? > Here are a couple of things >? > >? > [skarulkar at ldap2 ~]$ rpm -q ipa-client >? > ipa-client-3.0.0-26.el6_4.4.x86_64 > > What is the version on the client that is failing to enroll? > > rob > >? > >? > and my /etc/krb5.conf looks like .......... >? > ======================================= >? > 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 = ldap2.mydomain.com:88 >? >? ? master_kdc = ldap2.mydomain.com:88 >? >? ? admin_server = ldap2.mydomain.com:749 >? >? ? default_domain = mydomain.com >? >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt >? > 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 >? >? ? } >? > >? > ======================================= >? > >? > >? > Shreeraj >? > > ---------------------------------------------------------------------------------------- >? > >? > >? > Change is the only Constant ! >? > >? > >? > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden >? > > wrote: >? > Shree wrote: >? >? > 1) I have got a step furthur. My replica is not running CA Service. To >? >? > achieve this I had to remove the existing cert with this command >? >? > >? >? > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >? >? > >? >? > Now the replica looks like this >? >? > >? >? > skarulkar at ldap2 > tmp]$ sudo ipactl status >? >? > [sudo] password for skarulkar: >? >? > Directory Service: RUNNING >? >? > KDC Service: RUNNING >? >? > KPASSWD Service: RUNNING >? >? > MEMCACHE Service: RUNNING >? >? > HTTP Service: RUNNING >? >? > CA Service: RUNNING >? >? > [skarulkar at ldap2 > tmp]$ > >? > >? > The tracking failed with: >? > >? > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: >? > Improper format of Kerberos configuration file. >? > >? > It looks like it failed on this for most if not all the tracking. What >? > does /etc/krb5.conf look like? >? > >? >? > >? >? > 2) I am still not able to add client using ipa-client-install > using the >? >? > replica. >? > >? > The temporary krb5.conf that is used during enrollment has >? > dns_lookup_kdc=True so it is probably trying to contact the other KDC >? > and failing. >? > >? > What is the output of: >? > >? > $ rpm -q ipa-client >? > >? > >? > rob >? > >? > >? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 20 09:11:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Feb 2014 10:11:08 +0100 Subject: [Freeipa-users] Unexpected error at the end of ipa-replica-install In-Reply-To: <1392839274.26668.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1392839274.26668.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: <5305C6AC.8050101@redhat.com> On 02/19/2014 08:47 PM, Shree wrote: > Everything seems to be going well for all the 17 of 17 steps and then this > > [15/17]: configure clone certificate renewals > [16/17]: configure Server-Cert certificate renewal > [17/17]: Configure HTTP to proxy connections > Done configuring certificate server (pki-cad). > Restarting the directory and certificate servers > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-install.log for details: > CalledProcessError: Command '/sbin/service pki-cad stop pki-ca' returned non-zero exit status 4 > [root at ldap3 ~]# > > > Shreeraj > ---------------------------------------------------------------------------------------- > > Change is the only Constant ! Hello, Please follow this page: http://www.freeipa.org/page/Troubleshooting#Server_Installation Martin From jpazdziora at redhat.com Thu Feb 20 09:24:20 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 20 Feb 2014 10:24:20 +0100 Subject: [Freeipa-users] Free-IPA in an AWS Base Image In-Reply-To: References: Message-ID: <20140220092420.GG26583@redhat.com> On Mon, Feb 10, 2014 at 10:02:53PM -0800, Steve Severance wrote: > I want to create an AWS AMI that when it starts up will register itself > with a Free-IPA instance. The issue I have run into so far is every > instance when it starts up uses the original instances hostname. What do I > need to do to have free-ipa work in a DHCP environment like this? Is the AMI supposed to be internal to some organization / domain or is it supposed to be completely public? I slightly assume the first because you probably have some particular FreeIPA server instance hardcoded in the AMI. Is it acceptable to change the hostname of the instance to be in the domain managed by the FreeIPA server? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Thu Feb 20 10:29:58 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 20 Feb 2014 11:29:58 +0100 Subject: [Freeipa-users] Allow freeipa send password to user In-Reply-To: <5303D43E.7010601@redhat.com> References: <5303D43E.7010601@redhat.com> Message-ID: <20140220102958.GH26583@redhat.com> On Tue, Feb 18, 2014 at 04:44:30PM -0500, Dmitri Pal wrote: > On 02/17/2014 10:51 PM, barrykfl at gmail.com wrote: > >Is it possible to set allow password to send to user after user request. > > > >I used one of the self password service pwm but it seem it is not > >compatible to retriveal of password > >using cert request / Answer and questions retrieval > > Passwords can't be sent to the user. You can using administrative > account set a new password (i.e. do an admin reset) and send it to > the user but then user will be asked to change it on the first > authentication. Since I've heard the requirement for no password change forced on user upon their first login from multiple sides, I wonder if the current behaviour stems from some technical reason or if it's just a security approach which the FreeIPA admins should be able to override. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Thu Feb 20 10:38:44 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 20 Feb 2014 11:38:44 +0100 Subject: [Freeipa-users] About Windows client In-Reply-To: <53052ED3.3030906@redhat.com> References: <53052ED3.3030906@redhat.com> Message-ID: <20140220103844.GI26583@redhat.com> On Wed, Feb 19, 2014 at 05:23:15PM -0500, Dmitri Pal wrote: > > I want to summarize our position regarding joining Windows systems into IPA. > > 1) If you already have AD we recommend using this system with AD and > using trusts between AD and IPA. > 2) If you do not have AD then use Samba 4 instead of it. It would be > great when Samba 4 grows capability to establish trusts. Right now > it can't but there is an effort going on. If you are interested - > please contribute. > 3) If neither of the two options work for you you can configure > Windows system to work directly with IPA as described on the wiki. > It is an option of last resort because IPA does not provide the > services windows client expects. If this is good enough for you, > fine by us. > 4) Build a native Windows client (cred provider) for IPA using > latest Kerberos. IMO this would be really useful if someone does > that because we will not build this ourselves. With the native OTP > support in IPA it becomes a real business opportunity to provide a > native 2FA inside enterprise across multiple platforms. But please > do it open source way otherwise we would not recommend you ;-) Would it makes sense to make this into a freeipa.org wiki page? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Thu Feb 20 10:54:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Feb 2014 12:54:31 +0200 Subject: [Freeipa-users] Allow freeipa send password to user In-Reply-To: <20140220102958.GH26583@redhat.com> References: <5303D43E.7010601@redhat.com> <20140220102958.GH26583@redhat.com> Message-ID: <20140220105431.GH16644@redhat.com> On Thu, 20 Feb 2014, Jan Pazdziora wrote: >On Tue, Feb 18, 2014 at 04:44:30PM -0500, Dmitri Pal wrote: >> On 02/17/2014 10:51 PM, barrykfl at gmail.com wrote: >> >Is it possible to set allow password to send to user after user request. >> > >> >I used one of the self password service pwm but it seem it is not >> >compatible to retriveal of password >> >using cert request / Answer and questions retrieval >> >> Passwords can't be sent to the user. You can using administrative >> account set a new password (i.e. do an admin reset) and send it to >> the user but then user will be asked to change it on the first >> authentication. > >Since I've heard the requirement for no password change forced on user >upon their first login from multiple sides, I wonder if the current >behaviour stems from some technical reason or if it's just a security >approach which the FreeIPA admins should be able to override. There is no such thing as 'just' when taking security seriously, sorry. Any change of the password by someone other than the owner of it taints the password. Administrator setting the password taints it because what is known to more than one party cannot be considered secret anymore. If certain organization policy needs to override this, a sequence like $ kinit admin $ echo "nimda$NEWPASSWORD" | ipa passwd user $ echo -e "nimda$NEWPASSWORD\n$NEWPASSWORD\n$NEWPASSWORD" | kpasswd user would set $NEWPASSWORD for the user. You can certainly script it but I'd recommend think seriously how well this goes with data security regulations an organization could be subject to. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Feb 20 10:55:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Feb 2014 12:55:07 +0200 Subject: [Freeipa-users] About Windows client In-Reply-To: <20140220103844.GI26583@redhat.com> References: <53052ED3.3030906@redhat.com> <20140220103844.GI26583@redhat.com> Message-ID: <20140220105507.GI16644@redhat.com> On Thu, 20 Feb 2014, Jan Pazdziora wrote: >On Wed, Feb 19, 2014 at 05:23:15PM -0500, Dmitri Pal wrote: >> >> I want to summarize our position regarding joining Windows systems into IPA. >> >> 1) If you already have AD we recommend using this system with AD and >> using trusts between AD and IPA. >> 2) If you do not have AD then use Samba 4 instead of it. It would be >> great when Samba 4 grows capability to establish trusts. Right now >> it can't but there is an effort going on. If you are interested - >> please contribute. >> 3) If neither of the two options work for you you can configure >> Windows system to work directly with IPA as described on the wiki. >> It is an option of last resort because IPA does not provide the >> services windows client expects. If this is good enough for you, >> fine by us. >> 4) Build a native Windows client (cred provider) for IPA using >> latest Kerberos. IMO this would be really useful if someone does >> that because we will not build this ourselves. With the native OTP >> support in IPA it becomes a real business opportunity to provide a >> native 2FA inside enterprise across multiple platforms. But please >> do it open source way otherwise we would not recommend you ;-) > >Would it makes sense to make this into a freeipa.org wiki page? Yes, to the 'last resort' page, I think. -- / Alexander Bokovoy From Johan.Petersson at sscspace.com Thu Feb 20 12:25:28 2014 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Thu, 20 Feb 2014 12:25:28 +0000 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <6b3e625595ee4f8eaa593a93ee18b43b@SINPR04MB298.apcprd04.prod.outlook.com> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com>, <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com>, <558C15177F5E714F83334217C9A197DF014D126BFB@SSC-MBX1.ssc.internal>, <6b3e625595ee4f8eaa593a93ee18b43b@SINPR04MB298.apcprd04.prod.outlook.com> Message-ID: <558C15177F5E714F83334217C9A197DF014D12CE55@SSC-MBX2.ssc.internal> I do not have access to my lab environment at the moment to help you completely but this should put you on the right track i hope. This config enables Home Directories shared through NFS to IPA Linux Clients to also be accessible to Windows Clients through SAMBA when having a sync configuration between AD and IPA. System is a IPA client acting as NFS/SAMBA File Server The home directory is shared through NFS 4 krb5p and is automounted to Linux Clients. I presume that the IPA Client Configuration and NFS 4 shared Home Directories on the server are working properly already. You also need to have the AD/IPA sync and passsync working. Windows AD Server realm is adexample.com You can have more than one Kerberos realm in you krb5.conf so just add the AD realm under [realms] and [domain_realm]. [realms] EXAMPLE.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } ADEXAMPLE.COM = { kdc = ad.adexample.com admin_server = ad.adexample.com default_domain = adexample.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM .adexample.com = ADEXAMPLE.COM adexample.com = ADEXAMPLE.COM /etc/nsswitch.conf: passwd: files sss winbind group: files sss winbind Try this config in smb.conf /etc/samba/smb.conf: workgroup = ADEXAMPLE security = ads passdb backend = tdbsam realm = ADEXAMPLE.COM encrypt passwords = yes domain master = no local master = no preferred master = no socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 use sendfile = true idmap config * : backend = tdb idmap config * : range = 100000-299999 idmap config TEST : backend = rid idmap config TEST : range = 10000-99999 winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind refresh tickets = yes template homedir = /home/%U template shell = /bin/bash client use spnego = yes client ntlmv2 auth = yes restrict anonymous = 2 [homes] comment = Home Directories path = /home/%U browseable = no writable = yes valid users = %U force user = %U directory mode = 0700 force directory mode = 0700 create mode = 0600 force create mode = 0600 access based share enum = yes hide unreadable = yes If you use alternate home directory don't forget to set up SELinux for it properly with home_root_t/user_home_dir_t/user-home_t. Allow samba to share home directories: setsebool _P samba_enable_home_dirs on Join server to the AD: net ads join -U administrator Make sure smb and winbind are started and set to automatic start at reboots. Test that you get user and group information: wbinfo -u,getent passwd wbinfo -g,getent group Test: smbclient -L //servername.example.com -U username smbclient //servername.example.com/username -U username Try browse and create files/directories and check to see all permissions are 0700/0600 and the right user/group. Also don't forget to configure the Firewall on the server to allow for SAMBA. Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Wednesday, February 19, 2014 01:28 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA This is what I'd like to do, Linux users have nfs with samba for windows users. From what I can read however to get smba to work with AD I have to alter kerberos which is set to IPA...so I dont understand how you have it working. Currently Im trying to get samba just to work with a password set via smbpasswd but this is also failing, not sure if its a IPA interference issue or something else... regards Steven J ________________________________________ From: Johan Petersson Sent: Tuesday, 18 February 2014 8:18 p.m. To: Steven Jones; freeipa-users at redhat.com; dpal at redhat.com Subject: RE: [Freeipa-users] Setting up samba with IPA One solution that i have tested myself is to have IPA and AD sync with Samba as a server in a 2012 R2 Server AD. For shared directories used both by Windows and Linux clients like Home i used NFS 4 with Kerberos for Linux and Samba ADS for Windows. Same user could log in from both Windows and Linux with same password through winsync and passsync and get secured access with proper permissions on directories and files. Tested this setup out while i wait for IPA being able to handle all user accounts an resources in an IPA - AD trust. Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Tuesday, February 18, 2014 00:34 To: freeipa-users at redhat.com; dpal at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA Can we be clear here, Im not after SSO as such, I can sign in with the AD password but that is failing. Otherwise if I read you correctly I cant use IPA controlled samba with AD controlled windows hosts at all? So Im better to de-IPA samba and go back to the old samba method with a local password? regards Steven Jones Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 18 February 2014 12:04 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting up samba with IPA On 02/17/2014 05:49 PM, Steven Jones wrote: > Hi, > > So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? > > Ergo I have to remove IPA off the samba server? I think the setup when you have sync in place is a bit crafty. I know that people made it work in the past but with some assumptions that this is not an SSO. I mean you can't use a Window system and access Samba FS share when Samba FS is a member of IPA and IPA is in sync relations because user on Windows and user in IPA are two different users though they have same name Samba FS can't match the windows SID of the Windows user to the SID of the IPA user because there is no SID for IPA user. But on the other side I know that one can make Samba FS work with IPA, there have been articles about it. I am not sure what is the expectation about the clients in this case. The solution that we are working on is based on the trust. This part is not ready yet. Once ready Samba FS can be a member of the IPA domain, IPA would trust AD and then users from AD running Windows systems would be able to directly use Samba FS. This feature is in development right now. > regards > > Steven Jones > > ________________________________________ > From: Alexander Bokovoy > Sent: Tuesday, 18 February 2014 11:21 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On Mon, 17 Feb 2014, Steven Jones wrote: >> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >> enabled server OK. >> >> >> Is there a way to limit some users to CIFS only in IPA? > If you file system supports POSIX ACLs then simply set limits at the > file system level, it should work fine. > > http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html > >> Also however my AD connected windows7 machine with winsync and passsync >> in place to IPA wont connect. It doesnt seem to like the password....or >> user, unsure... > It doesn't like SID of that user and therefore doesn't think it is the > same user. There might be other reasons too, as we still haven't settled > down all bits to enable proper Windows integration for CIFS file > serving. > > -- > / Alexander Bokovoy > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Thu Feb 20 13:05:15 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Feb 2014 08:05:15 -0500 Subject: [Freeipa-users] Allow freeipa send password to user In-Reply-To: <20140220102958.GH26583@redhat.com> References: <5303D43E.7010601@redhat.com> <20140220102958.GH26583@redhat.com> Message-ID: <1392901515.22754.208.camel@willson.li.ssimo.org> On Thu, 2014-02-20 at 11:29 +0100, Jan Pazdziora wrote: > On Tue, Feb 18, 2014 at 04:44:30PM -0500, Dmitri Pal wrote: > > On 02/17/2014 10:51 PM, barrykfl at gmail.com wrote: > > >Is it possible to set allow password to send to user after user request. > > > > > >I used one of the self password service pwm but it seem it is not > > >compatible to retriveal of password > > >using cert request / Answer and questions retrieval > > > > Passwords can't be sent to the user. You can using administrative > > account set a new password (i.e. do an admin reset) and send it to > > the user but then user will be asked to change it on the first > > authentication. > > Since I've heard the requirement for no password change forced on user > upon their first login from multiple sides, I wonder if the current > behaviour stems from some technical reason or if it's just a security > approach which the FreeIPA admins should be able to override. It is a security measure, and also quite easy to work around. Working it around is left as an exercise to the reader. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Thu Feb 20 13:28:32 2014 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 20 Feb 2014 08:28:32 -0500 Subject: [Freeipa-users] Unofficial SSSD 1.9.x repository for RHEL 5 Message-ID: <53060300.3020309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Due to popular request, I am offering a completely unofficial and unsupported repository of the latest 1.9.x LTM bits for RHEL 5 and derivatives. The latest official version supported by the distribution is 1.5.x. These packages are built from the upstream sources using the same spec file that was used to generate the nightly builds back when 1.9.x was the master branch, so it's expected to work just fine. You can find the repository and instructions how to use it at: http://copr-fe.cloud.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/ Please do not file bugs against Bugzilla for issues discovered with these builds. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMGAwAACgkQeiVVYja6o6McygCdH6OGn//W3Po7XokoHLEOIzS+ 0VUAoK8mfaLdSzzoLpFZMLd/gFqNf5YY =xEFs -----END PGP SIGNATURE----- From dpal at redhat.com Thu Feb 20 15:08:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 10:08:50 -0500 Subject: [Freeipa-users] About Windows client In-Reply-To: <20140220105507.GI16644@redhat.com> References: <53052ED3.3030906@redhat.com> <20140220103844.GI26583@redhat.com> <20140220105507.GI16644@redhat.com> Message-ID: <53061A82.3060304@redhat.com> On 02/20/2014 05:55 AM, Alexander Bokovoy wrote: > On Thu, 20 Feb 2014, Jan Pazdziora wrote: >> On Wed, Feb 19, 2014 at 05:23:15PM -0500, Dmitri Pal wrote: >>> >>> I want to summarize our position regarding joining Windows systems >>> into IPA. >>> >>> 1) If you already have AD we recommend using this system with AD and >>> using trusts between AD and IPA. >>> 2) If you do not have AD then use Samba 4 instead of it. It would be >>> great when Samba 4 grows capability to establish trusts. Right now >>> it can't but there is an effort going on. If you are interested - >>> please contribute. >>> 3) If neither of the two options work for you you can configure >>> Windows system to work directly with IPA as described on the wiki. >>> It is an option of last resort because IPA does not provide the >>> services windows client expects. If this is good enough for you, >>> fine by us. >>> 4) Build a native Windows client (cred provider) for IPA using >>> latest Kerberos. IMO this would be really useful if someone does >>> that because we will not build this ourselves. With the native OTP >>> support in IPA it becomes a real business opportunity to provide a >>> native 2FA inside enterprise across multiple platforms. But please >>> do it open source way otherwise we would not recommend you ;-) >> >> Would it makes sense to make this into a freeipa.org wiki page? > Yes, to the 'last resort' page, I think. > Any volunteers? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Feb 20 15:11:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 10:11:20 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c! om> Message-ID: <53061B18.40001@redhat.com> On 02/19/2014 06:52 PM, Shree wrote: > Rob > You were right. After upgrading the client to the > ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning > during the client install that went something like > ================= > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to > always access the discovered server for all operations and will not > fail over to other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no]: yes > ================= > I continued by saying yes because in my case the master and the > replica are in different VLANs and failover is not possible for me. I > have tried in two hosts successfully and am hoping that does the trick. > > However I see one issue immediately that my sudo access does not seem > to work now on the newly added clients! Do you know what might be > happening? Are you using SSSD and SUDO integration? What version of sudo and sssd? See if this would help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden > wrote: > Shree wrote: > > root at test500 ~]# rpm -q ipa-client > > ipa-client-2.2.0-16.el6.x86_64 > > [root at test500 ~]# > > You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 > > Unfortunately our logging around discovery was rather horrible in 2.2.x > so it is difficult to know exactly what is going on. > > I believe the problem is that it is still doing DNS discovery even > though you've passed in a server name so it is setting up Kerberos to > look up the KDC which it finds but can't talk to. > > This should be fixed in the 3.0 packages so updating to those is the > preferred solution. > > For 2.x you can try the --force option which should make it skip some > discovery. > > rob > > > > > > > Shreeraj > > > ---------------------------------------------------------------------------------------- > > > > > > Change is the only Constant ! > > > > > > On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden > > > wrote: > > Shree wrote: > > > Here are a couple of things > > > > > > [skarulkar at ldap2 > ~]$ rpm -q ipa-client > > > ipa-client-3.0.0-26.el6_4.4.x86_64 > > > > What is the version on the client that is failing to enroll? > > > > rob > > > > > > > > and my /etc/krb5.conf looks like .......... > > > ======================================= > > > 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 = ldap2.mydomain.com:88 > > > master_kdc = ldap2.mydomain.com:88 > > > admin_server = ldap2.mydomain.com:749 > > > default_domain = mydomain.com > > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > > 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 > > > } > > > > > > ======================================= > > > > > > > > > Shreeraj > > > > > > ---------------------------------------------------------------------------------------- > > > > > > > > > Change is the only Constant ! > > > > > > > > > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden > > > > >> wrote: > > > Shree wrote: > > > > 1) I have got a step furthur. My replica is not running CA > Service. To > > > > achieve this I had to remove the existing cert with this command > > > > > > > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca > -force > > > > > > > > Now the replica looks like this > > > > > > > > skarulkar at ldap2 > > > >> tmp]$ sudo ipactl > status > > > > [sudo] password for skarulkar: > > > > Directory Service: RUNNING > > > > KDC Service: RUNNING > > > > KPASSWD Service: RUNNING > > > > MEMCACHE Service: RUNNING > > > > HTTP Service: RUNNING > > > > CA Service: RUNNING > > > > [skarulkar at ldap2 > > > > > > >> tmp]$ > > > > > > > > The tracking failed with: > > > > > > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: > > > Improper format of Kerberos configuration file. > > > > > > It looks like it failed on this for most if not all the tracking. What > > > does /etc/krb5.conf look like? > > > > > > > > > > > 2) I am still not able to add client using ipa-client-install > > using the > > > > replica. > > > > > > The temporary krb5.conf that is used during enrollment has > > > dns_lookup_kdc=True so it is probably trying to contact the other KDC > > > and failing. > > > > > > What is the output of: > > > > > > $ rpm -q ipa-client > > > > > > > > > rob > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 20 15:16:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 10:16:32 -0500 Subject: [Freeipa-users] Setting up samba with IPA In-Reply-To: <558C15177F5E714F83334217C9A197DF014D12CE55@SSC-MBX2.ssc.internal> References: <5301CC7D.6050903@redhat.com> , <20140217222118.GA25560@redhat.com> <523e1129631842e99584ca90acd785b3@SINPR04MB298.apcprd04.prod.outlook.com>, <5302956F.5010809@redhat.com>, <5e4ee5e374e24f3d89cfb38f4ec2f486@SINPR04MB298.apcprd04.prod.outlook.com>, <558C15177F5E714F83334217C9A197DF014D126BFB@SSC-MBX1.ssc.internal>, <6b3e625595ee4f8eaa593a93ee18b43b@SINPR04MB298.apcprd04.prod.outlook.com> <558C15177F5E714F83334217C9A197DF014D12CE55@SSC-MBX2.ssc.internal> Message-ID: <53061C50.70408@redhat.com> On 02/20/2014 07:25 AM, Johan Petersson wrote: > I do not have access to my lab environment at the moment to help you completely but this should put you on the right track i hope. > > This config enables Home Directories shared through NFS to IPA Linux Clients to also be accessible to Windows Clients through SAMBA when having a sync configuration between AD and IPA. > > System is a IPA client acting as NFS/SAMBA File Server > The home directory is shared through NFS 4 krb5p and is automounted to Linux Clients. > I presume that the IPA Client Configuration and NFS 4 shared Home Directories on the server are working properly already. You also need to have the AD/IPA sync and passsync working. > > Windows AD Server realm is adexample.com > > You can have more than one Kerberos realm in you krb5.conf so just add the AD realm under [realms] and [domain_realm]. > > [realms] > EXAMPLE.COM = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > ADEXAMPLE.COM = { > kdc = ad.adexample.com > admin_server = ad.adexample.com > default_domain = adexample.com > } > [domain_realm] > .example.com = EXAMPLE.COM > example.com = EXAMPLE.COM > .adexample.com = ADEXAMPLE.COM > adexample.com = ADEXAMPLE.COM > > /etc/nsswitch.conf: > > passwd: files sss winbind > group: files sss winbind > > Try this config in smb.conf > /etc/samba/smb.conf: > > workgroup = ADEXAMPLE > > security = ads > passdb backend = tdbsam > realm = ADEXAMPLE.COM > encrypt passwords = yes > domain master = no > local master = no > preferred master = no > socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 > use sendfile = true > idmap config * : backend = tdb > idmap config * : range = 100000-299999 > idmap config TEST : backend = rid > idmap config TEST : range = 10000-99999 > > winbind separator = + > winbind enum users = yes > winbind enum groups = yes > winbind use default domain = yes > winbind nested groups = yes > winbind refresh tickets = yes > template homedir = /home/%U > template shell = /bin/bash > client use spnego = yes > client ntlmv2 auth = yes > restrict anonymous = 2 > > > [homes] > comment = Home Directories > path = /home/%U > browseable = no > writable = yes > valid users = %U > force user = %U > directory mode = 0700 > force directory mode = 0700 > create mode = 0600 > force create mode = 0600 > access based share enum = yes > hide unreadable = yes > > If you use alternate home directory don't forget to set up SELinux for it properly with home_root_t/user_home_dir_t/user-home_t. > > Allow samba to share home directories: > > setsebool _P samba_enable_home_dirs on > > Join server to the AD: > net ads join -U administrator > > Make sure smb and winbind are started and set to automatic start at reboots. > > Test that you get user and group information: > wbinfo -u,getent passwd > wbinfo -g,getent group > > Test: > smbclient -L //servername.example.com -U username > > smbclient //servername.example.com/username -U username > > Try browse and create files/directories and check to see all permissions are 0700/0600 and the right user/group. > Also don't forget to configure the Firewall on the server to allow for SAMBA. Johan, would you mind creating a HOWTO page on FreeIPA wiki? > Regards, > Johan > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Wednesday, February 19, 2014 01:28 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > This is what I'd like to do, Linux users have nfs with samba for windows users. From what I can read however to get smba to work with AD I have to alter kerberos which is set to IPA...so I dont understand how you have it working. > > Currently Im trying to get samba just to work with a password set via smbpasswd but this is also failing, not sure if its a IPA interference issue or something else... > > > regards > > Steven J > ________________________________________ > From: Johan Petersson > Sent: Tuesday, 18 February 2014 8:18 p.m. > To: Steven Jones; freeipa-users at redhat.com; dpal at redhat.com > Subject: RE: [Freeipa-users] Setting up samba with IPA > > One solution that i have tested myself is to have IPA and AD sync with Samba as a server in a 2012 R2 Server AD. > For shared directories used both by Windows and Linux clients like Home i used NFS 4 with Kerberos for Linux and Samba ADS for Windows. > Same user could log in from both Windows and Linux with same password through winsync and passsync and get secured access with proper permissions on directories and files. > Tested this setup out while i wait for IPA being able to handle all user accounts an resources in an IPA - AD trust. > > Regards, > Johan > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Tuesday, February 18, 2014 00:34 > To: freeipa-users at redhat.com; dpal at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > Can we be clear here, > > Im not after SSO as such, I can sign in with the AD password but that is failing. > > Otherwise if I read you correctly I cant use IPA controlled samba with AD controlled windows hosts at all? > > So Im better to de-IPA samba and go back to the old samba method with a local password? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University ITS, > > Level 8 Rankin Brown Building, > > Wellington, NZ > > 6012 > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal > Sent: Tuesday, 18 February 2014 12:04 p.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting up samba with IPA > > On 02/17/2014 05:49 PM, Steven Jones wrote: >> Hi, >> >> So what you are saying is AD clients and IPA enabled samba servers dont work as a solution yet? >> >> Ergo I have to remove IPA off the samba server? > I think the setup when you have sync in place is a bit crafty. > I know that people made it work in the past but with some assumptions > that this is not an SSO. > I mean you can't use a Window system and access Samba FS share when > Samba FS is a member of IPA and IPA is in sync relations because user on > Windows and user in IPA are two different users though they have same > name Samba FS can't match the windows SID of the Windows user to the SID > of the IPA user because there is no SID for IPA user. > But on the other side I know that one can make Samba FS work with IPA, > there have been articles about it. I am not sure what is the expectation > about the clients in this case. > > The solution that we are working on is based on the trust. This part is > not ready yet. Once ready Samba FS can be a member of the IPA domain, > IPA would trust AD and then users from AD running Windows systems would > be able to directly use Samba FS. This feature is in development right now. > >> regards >> >> Steven Jones >> >> ________________________________________ >> From: Alexander Bokovoy >> Sent: Tuesday, 18 February 2014 11:21 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Setting up samba with IPA >> >> On Mon, 17 Feb 2014, Steven Jones wrote: >>> I seem to have got a RHEL6 workstation doing smbclient to an IPA samba >>> enabled server OK. >>> >>> >>> Is there a way to limit some users to CIFS only in IPA? >> If you file system supports POSIX ACLs then simply set limits at the >> file system level, it should work fine. >> >> http://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html >> >>> Also however my AD connected windows7 machine with winsync and passsync >>> in place to IPA wont connect. It doesnt seem to like the password....or >>> user, unsure... >> It doesn't like SID of that user and therefore doesn't think it is the >> same user. There might be other reasons too, as we still haven't settled >> down all bits to enable proper Windows integration for CIFS file >> serving. >> >> -- >> / Alexander Bokovoy >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > This e-mail is private and confidential between the sender and the addressee. > In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Thu Feb 20 15:17:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Feb 2014 17:17:27 +0200 Subject: [Freeipa-users] About Windows client In-Reply-To: <53061A82.3060304@redhat.com> References: <53052ED3.3030906@redhat.com> <20140220103844.GI26583@redhat.com> <20140220105507.GI16644@redhat.com> <53061A82.3060304@redhat.com> Message-ID: <20140220151727.GP16644@redhat.com> On Thu, 20 Feb 2014, Dmitri Pal wrote: >On 02/20/2014 05:55 AM, Alexander Bokovoy wrote: >>On Thu, 20 Feb 2014, Jan Pazdziora wrote: >>>On Wed, Feb 19, 2014 at 05:23:15PM -0500, Dmitri Pal wrote: >>>> >>>>I want to summarize our position regarding joining Windows >>>>systems into IPA. >>>> >>>>1) If you already have AD we recommend using this system with AD and >>>>using trusts between AD and IPA. >>>>2) If you do not have AD then use Samba 4 instead of it. It would be >>>>great when Samba 4 grows capability to establish trusts. Right now >>>>it can't but there is an effort going on. If you are interested - >>>>please contribute. >>>>3) If neither of the two options work for you you can configure >>>>Windows system to work directly with IPA as described on the wiki. >>>>It is an option of last resort because IPA does not provide the >>>>services windows client expects. If this is good enough for you, >>>>fine by us. >>>>4) Build a native Windows client (cred provider) for IPA using >>>>latest Kerberos. IMO this would be really useful if someone does >>>>that because we will not build this ourselves. With the native OTP >>>>support in IPA it becomes a real business opportunity to provide a >>>>native 2FA inside enterprise across multiple platforms. But please >>>>do it open source way otherwise we would not recommend you ;-) >>> >>>Would it makes sense to make this into a freeipa.org wiki page? >>Yes, to the 'last resort' page, I think. >> >Any volunteers? Done. -- / Alexander Bokovoy From hmorris at ilstechnology.com Thu Feb 20 16:01:59 2014 From: hmorris at ilstechnology.com (Hendri Morris) Date: Thu, 20 Feb 2014 16:01:59 +0000 Subject: [Freeipa-users] Installing client on Amazon Linux EC2 Message-ID: I want have IPA clients that are on Amazon Linux (CentOS Derivative). I will be using CentOS for the IPA server but I can't seem to get the IPA client to install on Amazon Linux . The packages conflict and send me on to "dependency hell" Does anyone have experience installing FreeIPA or IPA client on Amazon Linux? Thanks Hendri This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Feb 20 16:09:55 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 20 Feb 2014 17:09:55 +0100 (CET) Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <32091.213.225.75.97.1389626956.squirrel@www.nixtra.com> <52D40786.5070401@redhat.com> <41383.213.225.75.97.1389627832.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> Message-ID: <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote: > > > On Tue, February 18, 2014 20:45, Rob Crittenden wrote: > >> Sigbjorn Lie wrote: >> >> >>>> On what machine are you trying to use the ipa tool? Is it one of the >>>> masters, all of them, enrolled clients? >>>> >>> >>> It's the same error message when the "ipa" command is run directly on any of the masters. >>> >>> >>> >>> And it's the same error message if I run the "ipa" command on any of the clients. >>> >>> >>> >>> I do not have a working "ipa" command anywhere anymore. >>> >>> >> >> Ok, let's test out the cert that ipa is using. Try this on any one of >> the masters: >> >> $ curl https://`hostname`/ipa/xml >> Should fail with Peer certificate cannot be authenticated with known CA >> certificates > > Yes, this did not work: > > > curl: (60) Peer certificate cannot be authenticated with known CA certificates > More details here: http://curl.haxx.se/docs/sslcerts.html > > > >> >> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml >> Should succeed in that you get the "you are not logged in" HTML page >> >> > > Indeed - this works. > > >> >> Ok, now unfortunately curl only handles the sql-style NSS databases so >> we can't fully reproduce it the same way that the IPA client is doing things, but here is an >> approximation: >> >> >> >> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >> /etc/ipa/ca.crt >> $ curl https://`hostname`/ipa/xml >> You should see the login page HTML >> >> > > Yes, I can now see the login page HTML. > > > >> >> If you stick a -v in there it'll give you more verbose output which >> would be useful if any of these fail in an unexpected way. >> >>>> Whatever is going on isn't likely related to the web server Apache >>>> database as you get the same error out of each one. The client log you sent confirmed that >>>> it tried to contact each master. The SSL error we're getting is that the client doesn't >>>> trust the CA that >>>> signed the server certificate so this appears to be a problem on the client, which begs the >>>> question: all clients or just this one? >>>> >>>> >>>> >>> >>> All clients. >>> >>> >>> >>> >>>> >>>> NSS is smart enough to handle multiple certificates, it should pick the >>>> newest one on startup. >>>> >>> >>> Ok. >>> >>> >>> >>> Where do you suggest I continue troubleshooting this issue? >>> >>> >> >> We can also tackle this on the server side. Let's verify the server cert: >> >> >> >> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >> >> > This produces the same output for all 3 servers: > > > certutil: certificate is valid > > >> >> This is verified on server startup so I expect it to be valid, but >> doesn't hurt to try. >> >> Restarting the Apache process might be something to try as changes to >> the NSS database aren't picked up until a restart. >> > > I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt" on ipa03, > and restarted httpd. > > The "ipa" command is now *working* on ipa03. :) > > > However it's *not working* a client who's /etc/ipa/default.conf points at ipa03. > > > Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? > > *ping* :) Regards, Siggi From shreerajkarulkar at yahoo.com Thu Feb 20 19:58:55 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Thu, 20 Feb 2014 11:58:55 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <53061B18.40001@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1392242244.23457.YahooMailNeo@web160105.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c! ! om> <53061B18.40001@redhat.com> Message-ID: <1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com> Can you help me figure out, below is some info on the existing working configuration one one of the clients 1)Sudo version 1.7.4p5 2)[root at test500 ~]# sssd --version 1.9.2 3)These are the uncommented lines in /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = mydomain.com [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 ipa_hostname = dns.mydomain.com chpass_provider = ipa ipa_server = ldap.mydomain.com ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com ldap_tls_cacert = /etc/ipa/ca.crt ======================================= 4)And these are the options in /etc/nsswitch.conf sudoers:??? files ldap passwd:???? files sss shadow:???? files sss group:????? files sss Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Thursday, February 20, 2014 7:20 AM, Dmitri Pal wrote: On 02/19/2014 06:52 PM, Shree wrote: Rob >You were right. After upgrading the client to the ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning during the client install that went something like >================= >Autodiscovery of servers for failover cannot work with this configuration. >If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. >Proceed with fixed values and no DNS discovery? [no]: yes >================= > >I continued by saying yes because in my case the master and the replica are in different VLANs and failover is not possible for me. I have tried in two hosts successfully and am hoping that does the trick. > > >However I see one issue immediately that my sudo access does not seem to work now on the newly added clients! Do you know what might be happening? > >? Are you using SSSD and SUDO integration? What version of sudo and sssd? See if this would help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden wrote: > >Shree wrote: >> root at test500 ~]# rpm -q ipa-client >> ipa-client-2.2.0-16.el6.x86_64 >> [root at test500 ~]# > >You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 > >Unfortunately our logging around discovery was rather horrible in 2.2.x >so it is difficult to know exactly what is going on. > >I believe the problem is that it is still doing DNS discovery even >though you've passed in a server name so it is setting up Kerberos to >look up the KDC which it finds but can't talk to. > >This should be fixed in the 3.0 packages so updating to those is the >preferred solution. > >For 2.x you can try the --force option which should make it skip some >discovery. > >rob > >> >> >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden >> wrote: >> Shree wrote: >>? > Here are a couple of things >>? > >>? > [skarulkar at ldap2 ~]$ rpm -q ipa-client >>? > ipa-client-3.0.0-26.el6_4.4.x86_64 >> >> What is the version on the client that is failing to enroll? >> >> rob >> >>? > >>? > and my /etc/krb5.conf looks like .......... >>? > ======================================= >>? > 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 = ldap2.mydomain.com:88 >>? >? ? master_kdc = ldap2.mydomain.com:88 >>? >? ? admin_server = ldap2.mydomain.com:749 >>? >? ? default_domain = mydomain.com >>? >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt >>? > 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 >>? >? ? } >>? > >>? > ======================================= >>? > >>? > >>? > Shreeraj >>? > >> ---------------------------------------------------------------------------------------- >>? > >>? > >>? > Change is the only Constant ! >>? > >>? > >>? > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden >>? > > wrote: >>? > Shree wrote: >>? >? > 1) I have got a step furthur. My replica is not running CA Service. To >>? >? > achieve this I had to remove the existing cert with this command >>? >? > >>? >? > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>? >? > >>? >? > Now the replica looks like this >>? >? > >>? >? > skarulkar at ldap2 > > tmp]$ sudo ipactl status >>? >? > [sudo] password for skarulkar: >>? >? > Directory Service: RUNNING >>? >? > KDC Service: RUNNING >>? >? > KPASSWD Service: RUNNING >>? >? > MEMCACHE Service: RUNNING >>? >? > HTTP Service: RUNNING >>? >? > CA Service: RUNNING >>? >? > [skarulkar at ldap2 >> > tmp]$ >> >>? > >>? > The tracking failed with: >>? > >>? > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: >>? > Improper format of Kerberos configuration file. >>? > >>? > It looks like it failed on this for most if not all the tracking. What >>? > does /etc/krb5.conf look like? >>? > >>? >? > >>? >? > 2) I am still not able to add client using ipa-client-install >> using the >>? >? > replica. >>? > >>? > The temporary krb5.conf that is used during enrollment has >>? > dns_lookup_kdc=True so it is probably trying to contact the other KDC >>? > and failing. >>? > >>? > What is the output of: >>? > >>? > $ rpm -q ipa-client >>? > >>? > >>? > rob >>? > >>? > >>? > >> >> >> > > > > > > >_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 20 20:19:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Feb 2014 15:19:04 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> Message-ID: <53066338.3000800@redhat.com> Sigbjorn Lie wrote: > > > > On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote: >> > >> >> On Tue, February 18, 2014 20:45, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>> >>> >>>>> On what machine are you trying to use the ipa tool? Is it one of the >>>>> masters, all of them, enrolled clients? >>>>> >>>> >>>> It's the same error message when the "ipa" command is run directly on any of the masters. >>>> >>>> >>>> >>>> And it's the same error message if I run the "ipa" command on any of the clients. >>>> >>>> >>>> >>>> I do not have a working "ipa" command anywhere anymore. >>>> >>>> >>> >>> Ok, let's test out the cert that ipa is using. Try this on any one of >>> the masters: >>> >>> $ curl https://`hostname`/ipa/xml >>> Should fail with Peer certificate cannot be authenticated with known CA >>> certificates >> >> Yes, this did not work: >> >> >> curl: (60) Peer certificate cannot be authenticated with known CA certificates >> More details here: http://curl.haxx.se/docs/sslcerts.html >> >> >> >>> >>> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml >>> Should succeed in that you get the "you are not logged in" HTML page >>> >>> >> >> Indeed - this works. >> >> >>> >>> Ok, now unfortunately curl only handles the sql-style NSS databases so >>> we can't fully reproduce it the same way that the IPA client is doing things, but here is an >>> approximation: >>> >>> >>> >>> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>> /etc/ipa/ca.crt >>> $ curl https://`hostname`/ipa/xml >>> You should see the login page HTML >>> >>> >> >> Yes, I can now see the login page HTML. >> >> >> >>> >>> If you stick a -v in there it'll give you more verbose output which >>> would be useful if any of these fail in an unexpected way. >>> >>>>> Whatever is going on isn't likely related to the web server Apache >>>>> database as you get the same error out of each one. The client log you sent confirmed that >>>>> it tried to contact each master. The SSL error we're getting is that the client doesn't >>>>> trust the CA that >>>>> signed the server certificate so this appears to be a problem on the client, which begs the >>>>> question: all clients or just this one? >>>>> >>>>> >>>>> >>>> >>>> All clients. >>>> >>>> >>>> >>>> >>>>> >>>>> NSS is smart enough to handle multiple certificates, it should pick the >>>>> newest one on startup. >>>>> >>>> >>>> Ok. >>>> >>>> >>>> >>>> Where do you suggest I continue troubleshooting this issue? >>>> >>>> >>> >>> We can also tackle this on the server side. Let's verify the server cert: >>> >>> >>> >>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>> >>> >> This produces the same output for all 3 servers: >> >> >> certutil: certificate is valid >> >> >>> >>> This is verified on server startup so I expect it to be valid, but >>> doesn't hurt to try. >>> >>> Restarting the Apache process might be something to try as changes to >>> the NSS database aren't picked up until a restart. >>> >> >> I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt" on ipa03, >> and restarted httpd. >> >> The "ipa" command is now *working* on ipa03. :) >> >> >> However it's *not working* a client who's /etc/ipa/default.conf points at ipa03. >> >> >> Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? You shouldn't need to. Frankly I'm surprised this worked. What is the distro and what version of nss is installed? rob From sigbjorn at nixtra.com Thu Feb 20 20:33:31 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 20 Feb 2014 21:33:31 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53066338.3000800@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D4327D.10108@redhat.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> <53066338.3000800@redhat.com> Message-ID: <5306669B.3050507@nixtra.com> On 20/02/14 21:19, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> >> >> >> On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote: >>> >> >>> >>> On Tue, February 18, 2014 20:45, Rob Crittenden wrote: >>> >>>> Sigbjorn Lie wrote: >>>> >>>> >>>>>> On what machine are you trying to use the ipa tool? Is it one of the >>>>>> masters, all of them, enrolled clients? >>>>>> >>>>> >>>>> It's the same error message when the "ipa" command is run directly >>>>> on any of the masters. >>>>> >>>>> >>>>> >>>>> And it's the same error message if I run the "ipa" command on any >>>>> of the clients. >>>>> >>>>> >>>>> >>>>> I do not have a working "ipa" command anywhere anymore. >>>>> >>>>> >>>> >>>> Ok, let's test out the cert that ipa is using. Try this on any one of >>>> the masters: >>>> >>>> $ curl https://`hostname`/ipa/xml >>>> Should fail with Peer certificate cannot be authenticated with >>>> known CA >>>> certificates >>> >>> Yes, this did not work: >>> >>> >>> curl: (60) Peer certificate cannot be authenticated with known CA >>> certificates >>> More details here: http://curl.haxx.se/docs/sslcerts.html >>> >>> >>> >>>> >>>> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml >>>> Should succeed in that you get the "you are not logged in" HTML page >>>> >>>> >>> >>> Indeed - this works. >>> >>> >>>> >>>> Ok, now unfortunately curl only handles the sql-style NSS databases so >>>> we can't fully reproduce it the same way that the IPA client is >>>> doing things, but here is an >>>> approximation: >>>> >>>> >>>> >>>> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>>> /etc/ipa/ca.crt >>>> $ curl https://`hostname`/ipa/xml >>>> You should see the login page HTML >>>> >>>> >>> >>> Yes, I can now see the login page HTML. >>> >>> >>> >>>> >>>> If you stick a -v in there it'll give you more verbose output which >>>> would be useful if any of these fail in an unexpected way. >>>> >>>>>> Whatever is going on isn't likely related to the web server Apache >>>>>> database as you get the same error out of each one. The client >>>>>> log you sent confirmed that >>>>>> it tried to contact each master. The SSL error we're getting is >>>>>> that the client doesn't >>>>>> trust the CA that >>>>>> signed the server certificate so this appears to be a problem on >>>>>> the client, which begs the >>>>>> question: all clients or just this one? >>>>>> >>>>>> >>>>>> >>>>> >>>>> All clients. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> NSS is smart enough to handle multiple certificates, it should >>>>>> pick the >>>>>> newest one on startup. >>>>>> >>>>> >>>>> Ok. >>>>> >>>>> >>>>> >>>>> Where do you suggest I continue troubleshooting this issue? >>>>> >>>>> >>>> >>>> We can also tackle this on the server side. Let's verify the server >>>> cert: >>>> >>>> >>>> >>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>> >>>> >>> This produces the same output for all 3 servers: >>> >>> >>> certutil: certificate is valid >>> >>> >>>> >>>> This is verified on server startup so I expect it to be valid, but >>>> doesn't hurt to try. >>>> >>>> Restarting the Apache process might be something to try as changes to >>>> the NSS database aren't picked up until a restart. >>>> >>> >>> I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a >>> -i /etc/ipa/ca.crt" on ipa03, >>> and restarted httpd. >>> >>> The "ipa" command is now *working* on ipa03. :) >>> >>> >>> However it's *not working* a client who's /etc/ipa/default.conf >>> points at ipa03. >>> >>> >>> Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? > > You shouldn't need to. Frankly I'm surprised this worked. What is the > distro and what version of nss is installed? > > rob > This is RHEL 6.5 with nss-3.15.3-3.el6_5.x86_64. I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb before and after I updated it into text files, and diff'ed them. No differences was reported. Regards, Siggi From rcritten at redhat.com Thu Feb 20 20:38:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Feb 2014 15:38:27 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <5306669B.3050507@nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D463E4.2080006@nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> <53066338.3000800@redhat.com> <5306669B.3050507@nixtra.com> Message-ID: <530667C3.4090303@redhat.com> Sigbjorn Lie wrote: > On 20/02/14 21:19, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> >>> >>> >>> On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote: >>>> >>> >>>> >>>> On Tue, February 18, 2014 20:45, Rob Crittenden wrote: >>>> >>>>> Sigbjorn Lie wrote: >>>>> >>>>> >>>>>>> On what machine are you trying to use the ipa tool? Is it one of the >>>>>>> masters, all of them, enrolled clients? >>>>>>> >>>>>> >>>>>> It's the same error message when the "ipa" command is run directly >>>>>> on any of the masters. >>>>>> >>>>>> >>>>>> >>>>>> And it's the same error message if I run the "ipa" command on any >>>>>> of the clients. >>>>>> >>>>>> >>>>>> >>>>>> I do not have a working "ipa" command anywhere anymore. >>>>>> >>>>>> >>>>> >>>>> Ok, let's test out the cert that ipa is using. Try this on any one of >>>>> the masters: >>>>> >>>>> $ curl https://`hostname`/ipa/xml >>>>> Should fail with Peer certificate cannot be authenticated with >>>>> known CA >>>>> certificates >>>> >>>> Yes, this did not work: >>>> >>>> >>>> curl: (60) Peer certificate cannot be authenticated with known CA >>>> certificates >>>> More details here: http://curl.haxx.se/docs/sslcerts.html >>>> >>>> >>>> >>>>> >>>>> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml >>>>> Should succeed in that you get the "you are not logged in" HTML page >>>>> >>>>> >>>> >>>> Indeed - this works. >>>> >>>> >>>>> >>>>> Ok, now unfortunately curl only handles the sql-style NSS databases so >>>>> we can't fully reproduce it the same way that the IPA client is >>>>> doing things, but here is an >>>>> approximation: >>>>> >>>>> >>>>> >>>>> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>>>> /etc/ipa/ca.crt >>>>> $ curl https://`hostname`/ipa/xml >>>>> You should see the login page HTML >>>>> >>>>> >>>> >>>> Yes, I can now see the login page HTML. >>>> >>>> >>>> >>>>> >>>>> If you stick a -v in there it'll give you more verbose output which >>>>> would be useful if any of these fail in an unexpected way. >>>>> >>>>>>> Whatever is going on isn't likely related to the web server Apache >>>>>>> database as you get the same error out of each one. The client >>>>>>> log you sent confirmed that >>>>>>> it tried to contact each master. The SSL error we're getting is >>>>>>> that the client doesn't >>>>>>> trust the CA that >>>>>>> signed the server certificate so this appears to be a problem on >>>>>>> the client, which begs the >>>>>>> question: all clients or just this one? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> All clients. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> NSS is smart enough to handle multiple certificates, it should >>>>>>> pick the >>>>>>> newest one on startup. >>>>>>> >>>>>> >>>>>> Ok. >>>>>> >>>>>> >>>>>> >>>>>> Where do you suggest I continue troubleshooting this issue? >>>>>> >>>>>> >>>>> >>>>> We can also tackle this on the server side. Let's verify the server >>>>> cert: >>>>> >>>>> >>>>> >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> >>>>> >>>> This produces the same output for all 3 servers: >>>> >>>> >>>> certutil: certificate is valid >>>> >>>> >>>>> >>>>> This is verified on server startup so I expect it to be valid, but >>>>> doesn't hurt to try. >>>>> >>>>> Restarting the Apache process might be something to try as changes to >>>>> the NSS database aren't picked up until a restart. >>>>> >>>> >>>> I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a >>>> -i /etc/ipa/ca.crt" on ipa03, >>>> and restarted httpd. >>>> >>>> The "ipa" command is now *working* on ipa03. :) >>>> >>>> >>>> However it's *not working* a client who's /etc/ipa/default.conf >>>> points at ipa03. >>>> >>>> >>>> Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? >> >> You shouldn't need to. Frankly I'm surprised this worked. What is the >> distro and what version of nss is installed? >> >> rob >> > > This is RHEL 6.5 with nss-3.15.3-3.el6_5.x86_64. > > I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb > before and after I updated it into text files, and diff'ed them. No > differences was reported. I can't think of a reason it would be using the sqlite database at all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find it hard to believe that this would be set EVERYWHERE. If we want to brute force things, trying strace against a client that isn't working to confirm that it is trying to open cert9 might give us a data point at least. rob From dpal at redhat.com Thu Feb 20 21:00:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 20 Feb 2014 16:00:00 -0500 Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c! ! om> <53061B18.40001@redhat.com> <1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com> Message-ID: <53066CD0.5080501@redhat.com> On 02/20/2014 02:58 PM, Shree wrote: > Can you help me figure out, below is some info on the existing working > configuration one one of the clients > 1)Sudo version 1.7.4p5 > > 2)[root at test500 ~]# sssd --version > 1.9.2 > > 3)These are the uncommented lines in /etc/sssd/sssd.conf > [sssd] > config_file_version = 2 > services = nss, pam > domains = mydomain.com > [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 > ipa_hostname = dns.mydomain.com > chpass_provider = ipa > ipa_server = ldap.mydomain.com > ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com > ldap_tls_cacert = /etc/ipa/ca.crt > ======================================= > 4)And these are the options in /etc/nsswitch.conf > sudoers: files ldap > passwd: files sss > shadow: files sss > group: files sss > > Shreeraj > ---------------------------------------------------------------------------------------- > > > Change is the only Constant ! > > > On Thursday, February 20, 2014 7:20 AM, Dmitri Pal > wrote: > On 02/19/2014 06:52 PM, Shree wrote: >> Rob >> You were right. After upgrading the client to the >> ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning >> during the client install that went something like >> ================= >> Autodiscovery of servers for failover cannot work with this >> configuration. >> If you proceed with the installation, services will be configured to >> always access the discovered server for all operations and will not >> fail over to other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no]: yes >> ================= >> I continued by saying yes because in my case the master and the >> replica are in different VLANs and failover is not possible for me. I >> have tried in two hosts successfully and am hoping that does the trick. >> >> However I see one issue immediately that my sudo access does not seem >> to work now on the newly added clients! Do you know what might be >> happening? > Are you using SSSD and SUDO integration? > What version of sudo and sssd? > See if this would help: > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > >> Shreeraj >> ---------------------------------------------------------------------------------------- >> >> >> Change is the only Constant ! >> >> >> On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden >> wrote: >> Shree wrote: >> > root at test500 ~]# rpm -q ipa-client >> > ipa-client-2.2.0-16.el6.x86_64 >> > [root at test500 ~]# >> >> You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 >> >> Unfortunately our logging around discovery was rather horrible in 2.2.x >> so it is difficult to know exactly what is going on. >> >> I believe the problem is that it is still doing DNS discovery even >> though you've passed in a server name so it is setting up Kerberos to >> look up the KDC which it finds but can't talk to. >> >> This should be fixed in the 3.0 packages so updating to those is the >> preferred solution. >> >> For 2.x you can try the --force option which should make it skip some >> discovery. >> >> rob >> >> > >> > >> > Shreeraj >> > >> ---------------------------------------------------------------------------------------- >> > >> > >> > Change is the only Constant ! >> > >> > >> > On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden >> > > wrote: >> > Shree wrote: >> > > Here are a couple of things >> > > >> > > [skarulkar at ldap2 > > ~]$ rpm -q ipa-client >> > > ipa-client-3.0.0-26.el6_4.4.x86_64 >> > >> > What is the version on the client that is failing to enroll? >> > >> > rob >> > >> > > >> > > and my /etc/krb5.conf looks like .......... >> > > ======================================= >> > > 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 = ldap2.mydomain.com:88 >> > > master_kdc = ldap2.mydomain.com:88 >> > > admin_server = ldap2.mydomain.com:749 >> > > default_domain = mydomain.com >> > > pkinit_anchors = FILE:/etc/ipa/ca.crt >> > > 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 >> > > } >> > > >> > > ======================================= >> > > >> > > >> > > Shreeraj >> > > >> > >> ---------------------------------------------------------------------------------------- >> > > >> > > >> > > Change is the only Constant ! >> > > >> > > >> > > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden >> > > >> >> wrote: >> > > Shree wrote: >> > > > 1) I have got a step furthur. My replica is not running CA >> Service. To >> > > > achieve this I had to remove the existing cert with this command >> > > > >> > > > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca >> -force >> > > > >> > > > Now the replica looks like this >> > > > >> > > > skarulkar at ldap2 >> > >> >> > >> tmp]$ sudo >> ipactl status >> > > > [sudo] password for skarulkar: >> > > > Directory Service: RUNNING >> > > > KDC Service: RUNNING >> > > > KPASSWD Service: RUNNING >> > > > MEMCACHE Service: RUNNING >> > > > HTTP Service: RUNNING >> > > > CA Service: RUNNING >> > > > [skarulkar at ldap2 >> > >> >> >> > >> tmp]$ >> > >> > > >> > > The tracking failed with: >> > > >> > > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos >> library: >> > > Improper format of Kerberos configuration file. >> > > >> > > It looks like it failed on this for most if not all the tracking. >> What >> > > does /etc/krb5.conf look like? >> > > >> > > > >> > > > 2) I am still not able to add client using ipa-client-install >> > using the >> > > > replica. >> > > >> > > The temporary krb5.conf that is used during enrollment has >> > > dns_lookup_kdc=True so it is probably trying to contact the other KDC >> > > and failing. >> > > >> > > What is the output of: >> > > >> > > $ rpm -q ipa-client >> > > >> > > >> > > rob >> > > >> > > >> > > >> > >> > >> > >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > It seems like you do not use SSSD integration so turning the debug on sudo and seeing what it is doing is the next step. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Feb 20 21:44:04 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 20 Feb 2014 22:44:04 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <530667C3.4090303@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> <53066338.3000800@redhat.com> <5306669B.3050507@nixtra.com> <530667C3.4090303@redhat.com> Message-ID: <53067724.5070707@nixtra.com> On 20/02/14 21:38, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 20/02/14 21:19, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>>> >>>> >>>> >>>> On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote: >>>>> >>>> >>>>> >>>>> On Tue, February 18, 2014 20:45, Rob Crittenden wrote: >>>>> >>>>>> Sigbjorn Lie wrote: >>>>>> >>>>>> >>>>>>>> On what machine are you trying to use the ipa tool? Is it one >>>>>>>> of the >>>>>>>> masters, all of them, enrolled clients? >>>>>>>> >>>>>>> >>>>>>> It's the same error message when the "ipa" command is run directly >>>>>>> on any of the masters. >>>>>>> >>>>>>> >>>>>>> >>>>>>> And it's the same error message if I run the "ipa" command on any >>>>>>> of the clients. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I do not have a working "ipa" command anywhere anymore. >>>>>>> >>>>>>> >>>>>> >>>>>> Ok, let's test out the cert that ipa is using. Try this on any >>>>>> one of >>>>>> the masters: >>>>>> >>>>>> $ curl https://`hostname`/ipa/xml >>>>>> Should fail with Peer certificate cannot be authenticated with >>>>>> known CA >>>>>> certificates >>>>> >>>>> Yes, this did not work: >>>>> >>>>> >>>>> curl: (60) Peer certificate cannot be authenticated with known CA >>>>> certificates >>>>> More details here: http://curl.haxx.se/docs/sslcerts.html >>>>> >>>>> >>>>> >>>>>> >>>>>> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml >>>>>> Should succeed in that you get the "you are not logged in" HTML page >>>>>> >>>>>> >>>>> >>>>> Indeed - this works. >>>>> >>>>> >>>>>> >>>>>> Ok, now unfortunately curl only handles the sql-style NSS >>>>>> databases so >>>>>> we can't fully reproduce it the same way that the IPA client is >>>>>> doing things, but here is an >>>>>> approximation: >>>>>> >>>>>> >>>>>> >>>>>> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>>>>> /etc/ipa/ca.crt >>>>>> $ curl https://`hostname`/ipa/xml >>>>>> You should see the login page HTML >>>>>> >>>>>> >>>>> >>>>> Yes, I can now see the login page HTML. >>>>> >>>>> >>>>> >>>>>> >>>>>> If you stick a -v in there it'll give you more verbose output which >>>>>> would be useful if any of these fail in an unexpected way. >>>>>> >>>>>>>> Whatever is going on isn't likely related to the web server Apache >>>>>>>> database as you get the same error out of each one. The client >>>>>>>> log you sent confirmed that >>>>>>>> it tried to contact each master. The SSL error we're getting is >>>>>>>> that the client doesn't >>>>>>>> trust the CA that >>>>>>>> signed the server certificate so this appears to be a problem on >>>>>>>> the client, which begs the >>>>>>>> question: all clients or just this one? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> All clients. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> NSS is smart enough to handle multiple certificates, it should >>>>>>>> pick the >>>>>>>> newest one on startup. >>>>>>>> >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Where do you suggest I continue troubleshooting this issue? >>>>>>> >>>>>>> >>>>>> >>>>>> We can also tackle this on the server side. Let's verify the server >>>>>> cert: >>>>>> >>>>>> >>>>>> >>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>>> >>>>>> >>>>> This produces the same output for all 3 servers: >>>>> >>>>> >>>>> certutil: certificate is valid >>>>> >>>>> >>>>>> >>>>>> This is verified on server startup so I expect it to be valid, but >>>>>> doesn't hurt to try. >>>>>> >>>>>> Restarting the Apache process might be something to try as >>>>>> changes to >>>>>> the NSS database aren't picked up until a restart. >>>>>> >>>>> >>>>> I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a >>>>> -i /etc/ipa/ca.crt" on ipa03, >>>>> and restarted httpd. >>>>> >>>>> The "ipa" command is now *working* on ipa03. :) >>>>> >>>>> >>>>> However it's *not working* a client who's /etc/ipa/default.conf >>>>> points at ipa03. >>>>> >>>>> >>>>> Do I have to refresh the PKI CA in /etc/pki/nssdb on every client? >>> >>> You shouldn't need to. Frankly I'm surprised this worked. What is the >>> distro and what version of nss is installed? >>> >>> rob >>> >> >> This is RHEL 6.5 with nss-3.15.3-3.el6_5.x86_64. >> >> I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb >> before and after I updated it into text files, and diff'ed them. No >> differences was reported. > > I can't think of a reason it would be using the sqlite database at > all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find > it hard to believe that this would be set EVERYWHERE. > > If we want to brute force things, trying strace against a client that > isn't working to confirm that it is trying to open cert9 might give us > a data point at least. I have NSS_DEFAULT_DB_TYPE set to "sql". When I do a strace I can see that on /etc/pki/nssdb/cert9.db it does: "access", "stat", attempt "open" read-write which is denied, then "open" read only. Looks pretty normal? What is odd is the timestamp on the files in /etc/pki/nssdb/ on the different ipa servers ipa01 and ipa02, which is not working cert8.db is timestamped with the date we initially installed the ipa servers in 2012. cert9.db, key3.db, key4.db, secmod.db is timestamped in 2010, 2 years before the server was installed - so this must be the original file provided by the nss-sysinit package. ipa03, which is working after updating the nssdb: cert8.db and key3.db is timestamped with the date when I carried out the changes you proposed which this thread originally started with in january 2014 cert9.db and key4.db is timestamped with the date I ran the certutil command you recommended me to 2 days ago secmod.db is timestamped in 2010, 2 years before the server was installed. As I described earlier in this thread, I gave up on fixing the cert system on ipa03 and ended up removing it as a replica, creating a new replica file, and reinstalling using ipa-replica-install. This explains the date in january 2014. If cert9.db is the file being used, then the certificate cannot be present in this file, as it's never been updated on ipa01 and ipa02. If I run a "strace ipa user-show admin" and look for cert8.db where the certificate is present, nothing comes up, so I assume cert9.db is the only file being utilized? It would seem like this is the reason for why it's failing, it's looking in cert9.db and the certificate is in cert8.db. But why is it like this? Regards, Siggi From rcritten at redhat.com Thu Feb 20 22:08:11 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Feb 2014 17:08:11 -0500 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53067724.5070707@nixtra.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <52D94E22.2060207@redhat.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> <53066338.3000800@redhat.com> <5306669B.3050507@nixtra.com> <530667C3.4090303@redhat.com> <53067724.5070707@nixtra.com> Message-ID: <53067CCB.4040805@redhat.com> Sigbjorn Lie wrote: > On 20/02/14 21:38, Rob Crittenden wrote: >>> >>> I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb >>> before and after I updated it into text files, and diff'ed them. No >>> differences was reported. >> >> I can't think of a reason it would be using the sqlite database at >> all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find >> it hard to believe that this would be set EVERYWHERE. >> >> If we want to brute force things, trying strace against a client that >> isn't working to confirm that it is trying to open cert9 might give us >> a data point at least. > > I have NSS_DEFAULT_DB_TYPE set to "sql". Oh, ok, that's why then. You're telling NSS to use sqlite databases and we only configure the older database style so the client isn't finding its CA cert. So you can either not set that or migrate all the client databases. I'm a little surprised the servers aren't blowing up on you too. rob From genadipost at gmail.com Thu Feb 20 22:27:23 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 21 Feb 2014 00:27:23 +0200 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: <20140219083526.GD2781@localhost.localdomain> References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> <20140219083526.GD2781@localhost.localdomain> Message-ID: Update: For some reason the AD server has rebooted himself. After the reboot i couldn't preform kinit with AD users. I found a bugzilla that describes the symptoms that i experienced : https://bugzilla.redhat.com/show_bug.cgi?id=878564 Not sure if it is the same bug - the bugzilla reports bug in samba4-4.0.0-48.el6.rc4.x86_64 while my version is samba4-4.0.0-58.el6.rc4.x86_64 (after downgrade). I have rebooted the IPA server to see if it changes anything. After the reboot i was able to kinit with AD users, but not only that - now i am able to login with AD users to client machines. Any idea on what just happened? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Feb 20 22:40:48 2014 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 20 Feb 2014 23:40:48 +0100 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53067CCB.4040805@redhat.com> References: <42710.213.225.75.97.1389623431.squirrel@www.nixtra.com> <57646.213.225.75.97.1391180400.squirrel@www.nixtra.com> <52EBFA5C.4070601@redhat.com> <49983.213.225.75.97.1392384728.squirrel@www.nixtra.com> <52FE2842.6040105@redhat.com> <44342.213.225.75.97.1392390056.squirrel@www.nixtra.com> <52FE41D3.4070308@redhat.com> <58557.213.225.75.97.1392648026.squirrel@www.nixtra.com> <53022BE9.9090403@redhat.com> <52576.213.225.75.97.1392655204.squirrel@www.nixtra.com> <53023FD8.5060103@redhat.com> <46801.213.225.75.97.1392714347.squirrel@www.nixtra.com> <5303B870.8030703@redhat.com> <54162.213.225.75.97.1392813952.squirrel@www.nixtra.com> <18396.62.92.50.17.1392912595.squirrel@www.nixtra.com> <53066338.3000800@redhat.com> <5306669B.3050507@nixtra.com> <530667C3.4090303@redhat.com> <53067724.5070707@nixtra.com> <53067CCB.4040805@redhat.com> Message-ID: <53068470.7060509@nixtra.com> On 20/02/14 23:08, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 20/02/14 21:38, Rob Crittenden wrote: >>>> >>>> I am surprised too. I dumped the PKI CA certificate from >>>> /etc/pki/nssdb >>>> before and after I updated it into text files, and diff'ed them. No >>>> differences was reported. >>> >>> I can't think of a reason it would be using the sqlite database at >>> all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find >>> it hard to believe that this would be set EVERYWHERE. >>> >>> If we want to brute force things, trying strace against a client that >>> isn't working to confirm that it is trying to open cert9 might give us >>> a data point at least. >> >> I have NSS_DEFAULT_DB_TYPE set to "sql". > > Oh, ok, that's why then. You're telling NSS to use sqlite databases > and we only configure the older database style so the client isn't > finding its CA cert. > > So you can either not set that or migrate all the client databases. > I'm a little surprised the servers aren't blowing up on you too. > Ohh so true...unset NSS_DEFAULT_DB_TYPE and it's all working fine! I can't believe it was something this silly! I've found the file where the NSS_DEFAULT_DB_TYPE is set to "sql" for our environment. This file has not been changed since Sep 2012. It's only set for a select amount of our accounts (mine being one of them) - that's why the servers isn't blowing up. And is why the webui is still working... We installed IPA in early 2012 and I've not had issues using the "ipa" command on any machines until a few weeks ago - and yes, NSS_DEFAULT_DB_TYPE=sql has been in the environment for my account the whole time. We recently installed a set of patches upgrading our servers to RHEL 6.5+(some updates) from 6.4. It would seem like something changed with this set of patches. And it also explains why this did not happen in the test environment as the same accounts are not being utilised there. Thank you for your assistance resolving these issues we've had recently. :) Regards, Siggi From shreerajkarulkar at yahoo.com Fri Feb 21 04:52:19 2014 From: shreerajkarulkar at yahoo.com (Shree) Date: Thu, 20 Feb 2014 20:52:19 -0800 (PST) Subject: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC In-Reply-To: <53066CD0.5080501@redhat.com> References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FBFBDA.8030104@redhat.com> <1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah! ! oo.com> <52FCD9AD.5000502@redhat.com> <1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com> <52F! E5E83.70904@redhat.com> <1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com> <52FE7119.1070601@redhat.com> <1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5303B22A.9070709@redhat.com> <1! 392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com> <1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com> ! <53051B35.2050409@redhat.com> <1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com! > <53051F62.40405@redhat.com> <1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com! > <53052E64.3050903@redhat.com> <1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c! ! om> <53061B18.40001@redhat.com> <1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com> <53066CD0.5080501@redhat.! com> Message-ID: <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com> Dmitri, Rob, Lucas et al. Thank you for all your help and patience and pointing me to the right direction. I was able to fix? most of my issues. My setup is a little complex where I am trying to have a master and the replica in different networks and are in sync + each of them is serving a different set of hosts. ? Shreeraj ---------------------------------------------------------------------------------------- Change is the only Constant ! On Thursday, February 20, 2014 2:20 PM, Dmitri Pal wrote: On 02/20/2014 02:58 PM, Shree wrote: Can you help me figure out, below is some info on the existing working configuration one one of the clients >1)Sudo version 1.7.4p5 > >2)[root at test500 ~]# sssd --version >1.9.2 > >3)These are the uncommented lines in /etc/sssd/sssd.conf >[sssd] >config_file_version = 2 >services = nss, pam >domains = mydomain.com >[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 >ipa_hostname = dns.mydomain.com >chpass_provider = ipa >ipa_server = ldap.mydomain.com >ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com >ldap_tls_cacert = /etc/ipa/ca.crt > >======================================= >4)And these are the options in /etc/nsswitch.conf >sudoers:??? files ldap >passwd:???? files sss >shadow:???? files sss >group:????? files sss > > >Shreeraj >---------------------------------------------------------------------------------------- > >Change is the only Constant ! > > > >On Thursday, February 20, 2014 7:20 AM, Dmitri Pal wrote: > >On 02/19/2014 06:52 PM, Shree wrote: >Rob >>You were right. After upgrading the client to the ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning during the client install that went something like >>================= >>Autodiscovery of servers for failover cannot work with this configuration. >>If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. >>Proceed with fixed values and no DNS discovery? [no]: yes >>================= >> >>I continued by saying yes because in my case the master and the replica are in different VLANs and failover is not possible for me. I have tried in two hosts successfully and am hoping that does the trick. >> >> >>However I see one issue immediately that my sudo access does not seem to work now on the newly added clients! Do you know what might be happening? >> >>? Are you using SSSD and SUDO integration? >What version of sudo and sssd? >See if this would help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > > >Shreeraj >>---------------------------------------------------------------------------------------- >> >>Change is the only Constant ! >> >> >> >>On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden wrote: >> >>Shree wrote: >>> root at test500 ~]# rpm -q ipa-client >>> ipa-client-2.2.0-16.el6.x86_64 >>> [root at test500 ~]# >> >>You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 >> >>Unfortunately our logging around discovery was rather horrible in 2.2.x >>so it is difficult to know exactly what is going on. >> >>I believe the problem is that it is still doing DNS discovery even >>though you've passed in a server name so it is setting up Kerberos to >>look up the KDC which it finds but can't talk to. >> >>This should be fixed in the 3.0 packages so updating to those is the >>preferred solution. >> >>For 2.x you can try the --force option which should make it skip some >>discovery. >> >>rob >> >>> >>> >>> Shreeraj >>> ---------------------------------------------------------------------------------------- >>> >>> >>> Change is the only Constant ! >>> >>> >>> On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden >>> wrote: >>> Shree wrote: >>>? > Here are a couple of things >>>? > >>>? > [skarulkar at ldap2 ~]$ rpm -q ipa-client >>>? > ipa-client-3.0.0-26.el6_4.4.x86_64 >>> >>> What is the version on the client that is failing to enroll? >>> >>> rob >>> >>>? > >>>? > and my /etc/krb5.conf looks like .......... >>>? > ======================================= >>>? > 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 = ldap2.mydomain.com:88 >>>? >? ? master_kdc = ldap2.mydomain.com:88 >>>? >? ? admin_server = ldap2.mydomain.com:749 >>>? >? ? default_domain = mydomain.com >>>? >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt >>>? > 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 >>>? >? ? } >>>? > >>>? > ======================================= >>>? > >>>? > >>>? > Shreeraj >>>? > >>> ---------------------------------------------------------------------------------------- >>>? > >>>? > >>>? > Change is the only Constant ! >>>? > >>>? > >>>? > On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden >>>? > > wrote: >>>? > Shree wrote: >>>? >? > 1) I have got a step furthur. My replica is not running CA Service. To >>>? >? > achieve this I had to remove the existing cert with this command >>>? >? > >>>? >? > pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force >>>? >? > >>>? >? > Now the replica looks like this >>>? >? > >>>? >? > skarulkar at ldap2 >> > tmp]$ sudo ipactl status >>>? >? > [sudo] password for skarulkar: >>>? >? > Directory Service: RUNNING >>>? >? > KDC Service: RUNNING >>>? >? > KPASSWD Service: RUNNING >>>? >? > MEMCACHE Service: RUNNING >>>? >? > HTTP Service: RUNNING >>>? >? > CA Service: RUNNING >>>? >? > [skarulkar at ldap2 > >>> > tmp]$ >>> >>>? > >>>? > The tracking failed with: >>>? > >>>? > 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: >>>? > Improper format of Kerberos configuration file. >>>? > >>>? > It looks like it failed on this for most if not all the tracking. What >>>? > does /etc/krb5.conf look like? >>>? > >>>? >? > >>>? >? > 2) I am still not able to add client using ipa-client-install >>> using the >>>? >? > replica. >>>? > >>>? > The temporary krb5.conf that is used during enrollment has >>>? > dns_lookup_kdc=True so it is probably trying to contact the other KDC >>>? > and failing. >>>? > >>>? > What is the output of: >>>? > >>>? > $ rpm -q ipa-client >>>? > >>>? > >>>? > rob >>>? > >>>? > >>>? > >>> >>> >>> >> >> >> >> >> >> >>_______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users > > >-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ > >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users > > It seems like you do not use SSSD integration so turning the debug on sudo and seeing what it is doing is the next step. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Feb 21 15:38:48 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 21 Feb 2014 10:38:48 -0500 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> <20140219083526.GD2781@localhost.localdomain> Message-ID: <1392997128.22754.323.camel@willson.li.ssimo.org> On Fri, 2014-02-21 at 00:27 +0200, Genadi Postrilko wrote: > Update: > For some reason the AD server has rebooted himself. > After the reboot i couldn't preform kinit with AD users. > I found a bugzilla that describes the symptoms that i experienced : > https://bugzilla.redhat.com/show_bug.cgi?id=878564 > Not sure if it is the same bug - the bugzilla reports bug in > samba4-4.0.0-48.el6.rc4.x86_64 > while my version is samba4-4.0.0-58.el6.rc4.x86_64 (after downgrade). > > I have rebooted the IPA server to see if it changes anything. > After the reboot i was able to kinit with AD users, but not only that - now > i am able to > login with AD users to client machines. > > Any idea on what just happened? Sounds like a bug in windbindd which we currently use to talk to the Windows DCs for this functionality. Apparently winbindd failed to detect the DC came back online. A restart of the ipa server caused winbindd to restart and retry to get online. Can you please open a bug to track this issue ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tmaugh at boingo.com Fri Feb 21 17:20:40 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 21 Feb 2014 17:20:40 +0000 Subject: [Freeipa-users] adding ubuntu client to red hat server Message-ID: <6FB698E172A95F49BE009B36D56F53E2277AD1@EXCHMB1-ELS.BWINC.local> Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd tmaugh at boingo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Feb 21 17:32:02 2014 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 21 Feb 2014 09:32:02 -0800 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2277AD1@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2277AD1@EXCHMB1-ELS.BWINC.local> Message-ID: <81C415D67A794093BCFFE444902B790F@willsheldon.com> I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: > Hello, > > Another day another issue it seems :) > > so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. > > my error is as follows: > > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' > Failed to upload host SSH public keys. > > > Please help > > Thanks > > -Todd > tmaugh at boingo.com (mailto:tmaugh at boingo.com) > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Feb 21 17:42:27 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 21 Feb 2014 17:42:27 +0000 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: <81C415D67A794093BCFFE444902B790F@willsheldon.com> References: <6FB698E172A95F49BE009B36D56F53E2277AD1@EXCHMB1-ELS.BWINC.local>, <81C415D67A794093BCFFE444902B790F@willsheldon.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E2277AF4@EXCHMB1-ELS.BWINC.local> thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this root at se-idm-ubuntu-client-01:~# ipa-client-install --uninstall Unconfigured automount client failed: [Errno 2] No such file or directory certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Disabling client Kerberos and LDAP configurations Failed to remove krb5/LDAP configuration: isnt there a conf file I can remove or a a way to force the uninstall? ________________________________ From: Will Sheldon [mail at willsheldon.com] Sent: Friday, February 21, 2014 9:32 AM To: Todd Maugh Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd tmaugh at boingo.com _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at willsheldon.com Fri Feb 21 17:46:11 2014 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 21 Feb 2014 09:46:11 -0800 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2277AF4@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2277AF4@EXCHMB1-ELS.BWINC.local> Message-ID: <6EEF5349484147018342A0A14AAEB315@willsheldon.com> I also ran into this problem. I ended up using vm?s to test and just reverting to snapshots. I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ??force'?) Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: > thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this > > root at se-idm-ubuntu-client-01:~# ipa-client-install --uninstall > Unconfigured automount client failed: [Errno 2] No such file or directory > certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > Disabling client Kerberos and LDAP configurations > Failed to remove krb5/LDAP configuration: > > isnt there a conf file I can remove or a a way to force the uninstall? > > > From: Will Sheldon [mail at willsheldon.com (mailto:mail at willsheldon.com)] > Sent: Friday, February 21, 2014 9:32 AM > To: Todd Maugh > Cc: freeipa-users at redhat.com (mailto:freeipa-users at redhat.com) > Subject: Re: [Freeipa-users] adding ubuntu client to red hat server > > > I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. > > My script looks like: > > #revert reported version of ipapython so keys will upload properly (backup first tho) > cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak > sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py > > # install! > ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS > > #revert change to the ipapython version back again > #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py > > > > > > Kind regards, > > Will Sheldon > +1.778-689-1244 > > > On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: > > > Hello, > > > > Another day another issue it seems :) > > > > so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. > > > > my error is as follows: > > > > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > > host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' > > Failed to upload host SSH public keys. > > > > > > Please help > > > > Thanks > > > > -Todd > > tmaugh at boingo.com (mailto:tmaugh at boingo.com) > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaugh at boingo.com Fri Feb 21 17:55:47 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 21 Feb 2014 17:55:47 +0000 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: <6EEF5349484147018342A0A14AAEB315@willsheldon.com> References: <6FB698E172A95F49BE009B36D56F53E2277AF4@EXCHMB1-ELS.BWINC.local>, <6EEF5349484147018342A0A14AAEB315@willsheldon.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E2277B40@EXCHMB1-ELS.BWINC.local> OK I got it to go through with this but i don't understand the errors cause it didn't seem to work. Domain boingo.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm BOINGO.COM trying https://se-idm-01.boingo.com/ipa/xml Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' Hostname (se-idm-ubuntu-client-01.boingo.com) not found in DNS Failed to update DNS records. certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' Could not update DNS SSHFP records. ________________________________ From: Will Sheldon [mail at willsheldon.com] Sent: Friday, February 21, 2014 9:46 AM To: Todd Maugh Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I also ran into this problem. I ended up using vm?s to test and just reverting to snapshots. I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ??force'?) Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this root at se-idm-ubuntu-client-01:~# ipa-client-install --uninstall Unconfigured automount client failed: [Errno 2] No such file or directory certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Disabling client Kerberos and LDAP configurations Failed to remove krb5/LDAP configuration: isnt there a conf file I can remove or a a way to force the uninstall? ________________________________ From: Will Sheldon [mail at willsheldon.com] Sent: Friday, February 21, 2014 9:32 AM To: Todd Maugh Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd tmaugh at boingo.com _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Fri Feb 21 18:15:52 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 21 Feb 2014 13:15:52 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out Message-ID: <530797D8.5040101@damascusgrp.com> I'm getting ready to leave for the weekend, and this isn't the kind of thing I want to track down on a Friday, but if anyone has any ideas for things I should look at come Monday morning, I'd be very appreciative. I've got a system with 12 replicas, and no matter which IPA server I log into and try to run "ipa" CLI commands on (even "ipa help"), I get my session terminated. I also tried from a client system that has the ipatools rpm installed, and in that case I got bounced out of my sudo'd root session. I need to figure this out because something's obviously amiss, and we have discovered a number of systems that are lacking Kerberos keys. I was hoping the CLI would provide the mechanism to get them fixed. We're also trying to track down a 6-10 second delay every time a user logs in using SSSD to authenticate; the password check passes almost instantly, but something is taking up an additional bunch of time and my users are starting to complain. So I need to get past this so I can debug that. Thanks, and have a great weekend, all. -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Fri Feb 21 18:27:55 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 21 Feb 2014 19:27:55 +0100 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530797D8.5040101@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> Message-ID: <20140221182755.GF6016@hendrix.brq.redhat.com> On Fri, Feb 21, 2014 at 01:15:52PM -0500, Bret Wortman wrote: > I'm getting ready to leave for the weekend, and this isn't the kind > of thing I want to track down on a Friday, but if anyone has any > ideas for things I should look at come Monday morning, I'd be very > appreciative. > > I've got a system with 12 replicas, and no matter which IPA server I > log into and try to run "ipa" CLI commands on (even "ipa help"), I > get my session terminated. I also tried from a client system that > has the ipatools rpm installed, and in that case I got bounced out > of my sudo'd root session. I'm not sure I understand, does the login itself fail or do you log in fine, but running 'ipa' kicks you out? Does login as root (or a local, non-ipa user) work? > > I need to figure this out because something's obviously amiss, and > we have discovered a number of systems that are lacking Kerberos > keys. I was hoping the CLI would provide the mechanism to get them > fixed. We're also trying to track down a 6-10 second delay every > time a user logs in using SSSD to authenticate; the password check > passes almost instantly, but something is taking up an additional > bunch of time and my users are starting to complain. So I need to > get past this so I can debug that. What SSSD version is this? Can we see the logs to take a look where the delay is? From rcritten at redhat.com Fri Feb 21 18:36:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 13:36:02 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530797D8.5040101@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> Message-ID: <53079C92.4080809@redhat.com> Bret Wortman wrote: > I'm getting ready to leave for the weekend, and this isn't the kind of > thing I want to track down on a Friday, but if anyone has any ideas for > things I should look at come Monday morning, I'd be very appreciative. > > I've got a system with 12 replicas, and no matter which IPA server I log > into and try to run "ipa" CLI commands on (even "ipa help"), I get my > session terminated. I also tried from a client system that has the > ipatools rpm installed, and in that case I got bounced out of my sudo'd > root session. > > I need to figure this out because something's obviously amiss, and we > have discovered a number of systems that are lacking Kerberos keys. I > was hoping the CLI would provide the mechanism to get them fixed. We're > also trying to track down a 6-10 second delay every time a user logs in > using SSSD to authenticate; the password check passes almost instantly, > but something is taking up an additional bunch of time and my users are > starting to complain. So I need to get past this so I can debug that. > > Thanks, and have a great weekend, all. For the life of me I can't figure out what the ipa command might do that would log you out. I think brute force might be a way to go with this: strace -f o /tmp/out ipa help Then go back in and see what happened. As for login delay you may want to pick a client system and bump up the sssd debug level and see if that provides any clues. rob From mail at willsheldon.com Fri Feb 21 18:51:14 2014 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 21 Feb 2014 10:51:14 -0800 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2277B40@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E2277B40@EXCHMB1-ELS.BWINC.local> Message-ID: Do you have your IPA server set as the name server for the client in /etc/resolv.conf ? This is my install script, it may help you a bit. It does need a bit more work http://pastebin.com/mqdTZ3RU Ideally I?d like to convert it to an ansible playbook and have it from from the IPA host. Slightly unrelated, but have a read of this ticket, it makes some good suggestions at the bottom: https://bugs.launchpad.net/bugs/1280215 Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:55 AM, Todd Maugh wrote: > OK I got it to go through with this > > but i don't understand the errors cause it didn't seem to work. > > Domain boingo.com (http://boingo.com) is already configured in existing SSSD config, creating a new one. > The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm BOINGO.COM > trying https://se-idm-01.boingo.com/ipa/xml > Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' > Hostname (se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)) not found in DNS > Failed to update DNS records. > certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > Could not update DNS SSHFP records. > > > From: Will Sheldon [mail at willsheldon.com (mailto:mail at willsheldon.com)] > Sent: Friday, February 21, 2014 9:46 AM > To: Todd Maugh > Cc: freeipa-users at redhat.com (mailto:freeipa-users at redhat.com) > Subject: Re: [Freeipa-users] adding ubuntu client to red hat server > > I also ran into this problem. I ended up using vm?s to test and just reverting to snapshots. > > I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ??force'?) > > > Kind regards, > > Will Sheldon > +1.778-689-1244 > > > On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: > > > thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this > > > > root at se-idm-ubuntu-client-01:~# ipa-client-install --uninstall > > Unconfigured automount client failed: [Errno 2] No such file or directory > > certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > > certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > > Disabling client Kerberos and LDAP configurations > > Failed to remove krb5/LDAP configuration: > > > > isnt there a conf file I can remove or a a way to force the uninstall? > > > > > > From: Will Sheldon [mail at willsheldon.com (mailto:mail at willsheldon.com)] > > Sent: Friday, February 21, 2014 9:32 AM > > To: Todd Maugh > > Cc: freeipa-users at redhat.com (mailto:freeipa-users at redhat.com) > > Subject: Re: [Freeipa-users] adding ubuntu client to red hat server > > > > > > I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. > > > > My script looks like: > > > > #revert reported version of ipapython so keys will upload properly (backup first tho) > > cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak > > sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py > > > > # install! > > ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS > > > > #revert change to the ipapython version back again > > #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py > > > > > > > > > > > > Kind regards, > > > > Will Sheldon > > +1.778-689-1244 > > > > > > On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: > > > > > Hello, > > > > > > Another day another issue it seems :) > > > > > > so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. > > > > > > my error is as follows: > > > > > > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > > > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > > > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > > > host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' > > > Failed to upload host SSH public keys. > > > > > > > > > Please help > > > > > > Thanks > > > > > > -Todd > > > tmaugh at boingo.com (mailto:tmaugh at boingo.com) > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raubvogel at gmail.com Fri Feb 21 18:58:19 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 21 Feb 2014 13:58:19 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <53079C92.4080809@redhat.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> Message-ID: On Fri, Feb 21, 2014 at 1:36 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> >> I'm getting ready to leave for the weekend, and this isn't the kind of >> thing I want to track down on a Friday, but if anyone has any ideas for >> things I should look at come Monday morning, I'd be very appreciative. >> >> I've got a system with 12 replicas, and no matter which IPA server I log >> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >> session terminated. I also tried from a client system that has the >> ipatools rpm installed, and in that case I got bounced out of my sudo'd >> root session. >> >> I need to figure this out because something's obviously amiss, and we >> have discovered a number of systems that are lacking Kerberos keys. I >> was hoping the CLI would provide the mechanism to get them fixed. We're >> also trying to track down a 6-10 second delay every time a user logs in >> using SSSD to authenticate; the password check passes almost instantly, >> but something is taking up an additional bunch of time and my users are >> starting to complain. So I need to get past this so I can debug that. >> >> Thanks, and have a great weekend, all. > > > For the life of me I can't figure out what the ipa command might do that > would log you out. I think brute force might be a way to go with this: > > strace -f o /tmp/out ipa help > > Then go back in and see what happened. > > As for login delay you may want to pick a client system and bump up the sssd > debug level and see if that provides any clues. > I would also run ldapsearch in the client after you manually kinit'ed, to see which part of the show is boink. > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From bret.wortman at damascusgrp.com Fri Feb 21 19:03:42 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 21 Feb 2014 14:03:42 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <20140221182755.GF6016@hendrix.brq.redhat.com> References: <530797D8.5040101@damascusgrp.com> <20140221182755.GF6016@hendrix.brq.redhat.com> Message-ID: <5307A30E.8010407@damascusgrp.com> Sorry, I wasn't clear at all. Running the "ipa" command terminates my session. I can log in just fine. All the IPA services appear to be working. But no interaction via the command line is possible; it all ends with terminated sessions after about a 5 second pause: [ipamaster]# ipa help Connection to ipamaster closed. [desktop]$ On 02/21/2014 01:27 PM, Jakub Hrozek wrote: > On Fri, Feb 21, 2014 at 01:15:52PM -0500, Bret Wortman wrote: >> I'm getting ready to leave for the weekend, and this isn't the kind >> of thing I want to track down on a Friday, but if anyone has any >> ideas for things I should look at come Monday morning, I'd be very >> appreciative. >> >> I've got a system with 12 replicas, and no matter which IPA server I >> log into and try to run "ipa" CLI commands on (even "ipa help"), I >> get my session terminated. I also tried from a client system that >> has the ipatools rpm installed, and in that case I got bounced out >> of my sudo'd root session. > I'm not sure I understand, does the login itself fail or do you log in > fine, but running 'ipa' kicks you out? Does login as root (or a local, > non-ipa user) work? > >> I need to figure this out because something's obviously amiss, and >> we have discovered a number of systems that are lacking Kerberos >> keys. I was hoping the CLI would provide the mechanism to get them >> fixed. We're also trying to track down a 6-10 second delay every >> time a user logs in using SSSD to authenticate; the password check >> passes almost instantly, but something is taking up an additional >> bunch of time and my users are starting to complain. So I need to >> get past this so I can debug that. > What SSSD version is this? Can we see the logs to take a look where the > delay is? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From bret.wortman at damascusgrp.com Fri Feb 21 19:05:32 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 21 Feb 2014 14:05:32 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <53079C92.4080809@redhat.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> Message-ID: <5307A37C.30109@damascusgrp.com> Bizarre. # strace -f -o /tmp/out ipa help Usage: ipa [global-options] COMMAND [command-options] : : : # ipa help Connection to ipamaster closed. $ On 02/21/2014 01:36 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> I'm getting ready to leave for the weekend, and this isn't the kind of >> thing I want to track down on a Friday, but if anyone has any ideas for >> things I should look at come Monday morning, I'd be very appreciative. >> >> I've got a system with 12 replicas, and no matter which IPA server I log >> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >> session terminated. I also tried from a client system that has the >> ipatools rpm installed, and in that case I got bounced out of my sudo'd >> root session. >> >> I need to figure this out because something's obviously amiss, and we >> have discovered a number of systems that are lacking Kerberos keys. I >> was hoping the CLI would provide the mechanism to get them fixed. We're >> also trying to track down a 6-10 second delay every time a user logs in >> using SSSD to authenticate; the password check passes almost instantly, >> but something is taking up an additional bunch of time and my users are >> starting to complain. So I need to get past this so I can debug that. >> >> Thanks, and have a great weekend, all. > > For the life of me I can't figure out what the ipa command might do > that would log you out. I think brute force might be a way to go with > this: > > strace -f o /tmp/out ipa help > > Then go back in and see what happened. > > As for login delay you may want to pick a client system and bump up > the sssd debug level and see if that provides any clues. > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From raubvogel at gmail.com Fri Feb 21 19:13:36 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 21 Feb 2014 14:13:36 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <5307A37C.30109@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> Message-ID: On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman wrote: > Bizarre. > > # strace -f -o /tmp/out ipa help > > Usage: ipa [global-options] COMMAND [command-options] > > : > > : > > : > > > # ipa help > > Connection to ipamaster closed. > > $ > When you logged back in, did /tmp/out have anything interesting? > > > > On 02/21/2014 01:36 PM, Rob Crittenden wrote: >> >> Bret Wortman wrote: >>> >>> I'm getting ready to leave for the weekend, and this isn't the kind of >>> thing I want to track down on a Friday, but if anyone has any ideas for >>> things I should look at come Monday morning, I'd be very appreciative. >>> >>> I've got a system with 12 replicas, and no matter which IPA server I log >>> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >>> session terminated. I also tried from a client system that has the >>> ipatools rpm installed, and in that case I got bounced out of my sudo'd >>> root session. >>> >>> I need to figure this out because something's obviously amiss, and we >>> have discovered a number of systems that are lacking Kerberos keys. I >>> was hoping the CLI would provide the mechanism to get them fixed. We're >>> also trying to track down a 6-10 second delay every time a user logs in >>> using SSSD to authenticate; the password check passes almost instantly, >>> but something is taking up an additional bunch of time and my users are >>> starting to complain. So I need to get past this so I can debug that. >>> >>> Thanks, and have a great weekend, all. >> >> >> For the life of me I can't figure out what the ipa command might do that >> would log you out. I think brute force might be a way to go with this: >> >> strace -f o /tmp/out ipa help >> >> Then go back in and see what happened. >> >> As for login delay you may want to pick a client system and bump up the >> sssd debug level and see if that provides any clues. >> >> rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From tmaugh at boingo.com Fri Feb 21 19:29:35 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 21 Feb 2014 19:29:35 +0000 Subject: [Freeipa-users] Ubuntu Client HELL Message-ID: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local> IM in limbo here trying to solve this issue here is my out put with the debug root at se-idm-ubuntu-client-01:/var/lib/ipa-client/sysrestore# ipa-client-install -d --no-dns-sshfp --hostname=se-idm-ubuntu-client-01.boingo.com --force-join --domain=boingo.com --server=se-idm-01.boingo.com /usr/sbin/ipa-client-install was invoked with options: {'domain': 'boingo.com', 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': False, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': None, 'ca_cert_file': None, 'principal': None, 'keytab': None, 'hostname': 'se-idm-ubuntu-client-01.boingo.com', 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': False, 'conf_ssh': True, 'force_join': True, 'server': ['se-idm-01.boingo.com'], 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} missing options might be asked for interactively later Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' WARNING: ntpd time&date synchronization service will not be configured as conflicting service (chronyd) is enabled Use --force-ntpd option to disable it and force configuration of ntpd [IPA Discovery] Starting IPA discovery with domain=boingo.com, servers=['se-idm-01.boingo.com'], hostname=se-idm-ubuntu-client-01.boingo.com Server and domain forced [Kerberos realm search] Search DNS for TXT record of _kerberos.boingo.com DNS record not found: NXDOMAIN [LDAP server check] Verifying that se-idm-01.boingo.com (realm None) is an IPA server Init LDAP connection to: se-idm-01.boingo.com Search LDAP server for IPA base DN Check if naming context 'dc=boingo,dc=com' is for IPA Naming context 'dc=boingo,dc=com' is a valid IPA context Search for (objectClass=krbRealmContainer) in dc=boingo,dc=com (sub) Found: cn=BOINGO.COM,cn=kerberos,dc=boingo,dc=com Discovery result: Success; server=se-idm-01.boingo.com, domain=boingo.com, kdc=None, basedn=dc=boingo,dc=com Validated servers: se-idm-01.boingo.com will use discovered domain: boingo.com Using servers from command line, disabling DNS discovery will use provided server: se-idm-01.boingo.com Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: yes will use discovered realm: BOINGO.COM will use discovered basedn: dc=boingo,dc=com Hostname: se-idm-ubuntu-client-01.boingo.com Hostname source: Provided as option Realm: BOINGO.COM Realm source: Discovered from LDAP DNS records in se-idm-01.boingo.com DNS Domain: boingo.com DNS Domain source: Forced IPA Server: se-idm-01.boingo.com IPA Server source: Provided as option BaseDN: dc=boingo,dc=com BaseDN source: From IPA server ldap://se-idm-01.boingo.com:389 Continue to configure the system with these values? [no]: yes Starting external process args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r BOINGO.COM Process finished, return code=0 stdout= stderr=Removing principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Removed old keys for realm BOINGO.COM from /etc/krb5.keytab Starting external process args=/bin/hostname se-idm-ubuntu-client-01.boingo.com Process finished, return code=0 stdout= stderr= Backing up system configuration file '/etc/hostname' Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' User authorized to enroll computers: admin will use principal provided as option: admin Synchronizing time with KDC... Search DNS for SRV record of _ntp._udp.boingo.com DNS record not found: NXDOMAIN Starting external process args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com Process finished, return code=1 stdout= stderr= Starting external process args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com Process finished, return code=1 stdout= stderr= Starting external process args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com Process finished, return code=1 stdout= stderr= Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Writing Kerberos configuration to /tmp/tmpBuP7iE: #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = BOINGO.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] BOINGO.COM = { kdc = se-idm-01.boingo.com:88 master_kdc = se-idm-01.boingo.com:88 admin_server = se-idm-01.boingo.com:749 default_domain = boingo.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .boingo.com = BOINGO.COM boingo.com = BOINGO.COM Password for admin at BOINGO.COM: Starting external process args=kinit admin at BOINGO.COM Process finished, return code=0 stdout=Password for admin at BOINGO.COM: stderr= trying to retrieve CA cert via LDAP from se-idm-01.boingo.com flushing ldap://se-idm-01.boingo.com:389 from SchemaCache retrieving schema for SchemaCache url=ldap://se-idm-01.boingo.com:389 conn= Existing CA cert and Retrieved CA cert are identical Starting external process args=/usr/sbin/ipa-join -s se-idm-01.boingo.com -b dc=boingo,dc=com -d -h se-idm-ubuntu-client-01.boingo.com -f Process finished, return code=0 stdout= stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n se-idm-ubuntu-client-01.boingo.com\r\n \r\n \r\n nsosversion\r\n 3.2.0-58-generic\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n XML-RPC RESPONSE: \n \n \n \n \n fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n \n \n sshpubkeyfp\n \n F9:63:24:7C:AF:AF:10:F8:1E:C2:16:69:FE:EF:57:18 root at 1204base (ssh-dss)\n 85:E8:4E:22:E6:7E:73:0D:10:5C:CB:1A:FC:8B:DE:5C root at 1204base (ssh-rsa)\n B8:BF:50:00:03:BF:AD:71:34:28:CE:83:0A:74:5E:8A root at 1204base (ecdsa-sha2-nistp256)\n \n \n \n has_keytab\n 1\n \n \n ipasshpubkey\n \n ssh-dss AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= root at 1204base\n ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv root at 1204base\n ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= root at 1204base\n \n \n \n cn\n \n se-idm-ubuntu-client-01.boingo.com\n \n \n \n usercertificate\n \n \n MIIDqTCCApGgAwIBAgIBGjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpCT0lOR08uQ09NMR4w\n HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTQwMjIxMTc1MzI5WhcNMTYwMjIyMTc1\n MzI5WjBCMRMwEQYDVQQKEwpCT0lOR08uQ09NMSswKQYDVQQDEyJzZS1pZG0tdWJ1bnR1LWNsaWVu\n dC0wMS5ib2luZ28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2f//2Wz6UwUp\n EErhWDHE+maebFuN82TQnYoAkrDGkebMOmtbLIy8fa7BdY5VNf+bJrLZkoGVq5us9aTc+s1YX63P\n rmbPjFbO8+vL9I8IVIUutkUTNEhpVm0xiFe+n6jF7OXnjo/sfYZ1zT2QUyLN3TMF97hU2+QBItuJ\n XY7ChOWk++YeYjgPK0xkcjbMZkNGKxKFF1qURmZVvj0VLgUxX8UwwFQZZK2XEg1Iexa+4SsKhdJN\n wNagw1x99CiUXChn7V4lYZe8Uk7QDalGrgQTCVAIT+/9IpR94H6N68bHYA/hdBmV1JshTrL2Uhr0\n Z2eNSjv3bpHC7BqeyWLllLw55wIDAQABo4G2MIGzMB8GA1UdIwQYMBaAFC53PmsjH7HOB4yeCQkD\n z3yaIEbNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL3NlLWlkbS0wMS5ib2lu\n Z28uY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr\n BgEFBQcDAjAdBgNVHQ4EFgQU7XOSHg+lb/Yizi5G81VQAT0VPQswDQYJKoZIhvcNAQELBQADggEB\n AGL9mbEyxQSv9d1dbMIW1V4NOBOJFKYmEXKxuQtrOEUDTN7H7IGNm7grMgOMYzrLYs1ftRxXrySF\n d8k/B3q8LBV2RQ7d0pT67cRH+YV6csmtpZ+YSOYSR+0e6F6BIsMCAU8lsjA7qvVYuaFCc+wvdiIp\n rea4piqV+lxWp1m0b/mdFuCbLyXao+pr2F5JhCHueHnn14I3k+E78f07hQUccOuS0BELWo9chy+l\n co7djPuzeG8MKTTr7+9L47dqhKhrY4sHyS+LhaUf3Y+irbLxgeqiBIjkV4TVkfZNZg4b6NvajgKM\n L9bj5XRwrSAhv1YccwzE1GDOOrp2j3LRYIcEUok=\n \n \n \n \n krbextradata\n \n \n AAKVkgdTaG9zdC9zZS1pZG0tdWJ1bnR1LWNsaWVudC0wMS5ib2luZ28uY29tQEJPSU5HTy5DT00A\n \n \n \n \n has_password\n 0\n \n \n subject\n CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM\n \n \n ipacertificatesubjectbase\n \n O=BOINGO.COM\n \n \n \n sha1_fingerprint\n 60:5c:7f:f5:e7:77:b7:3c:0c:c8:c0:07:3f:c3:00:18:c1:dd:9d:af\n \n \n krblastsuccessfulauth\n \n 20140221181453Z\n \n \n \n serial_number\n 26\n \n \n managedby_host\n \n se-idm-ubuntu-client-01.boingo.com\n \n \n \n enrolledby_user\n \n admin\n \n \n \n dn\n fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n \n \n issuer\n CN=Certificate Authority,O=BOINGO.COM\n \n \n ipauniqueid\n \n 459b077c-9b20-11e3-89c9-782bcb03bc6d\n \n \n \n krbprincipalname\n \n host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM\n \n \n \n serverhostname\n \n se-idm-ubuntu-client-01\n \n \n \n objectclass\n \n ipaobject\n nshost\n ipahost\n pkiuser\n ipaservice\n krbprincipalaux\n krbprincipal\n ieee802device\n ipasshhost\n top\n ipaSshGroupOfPubKeys\n \n \n \n valid_not_before\n Fri Feb 21 17:53:29 2014 UTC\n \n \n valid_not_after\n Mon Feb 22 17:53:29 2016 UTC\n \n \n fqdn\n \n se-idm-ubuntu-client-01.boingo.com\n \n \n \n managing_host\n \n se-idm-ubuntu-client-01.boingo.com\n \n \n \n md5_fingerprint\n bb:dc:38:b3:19:ab:7c:07:27:31:f9:a7:78:a4:98:16\n \n \n serial_number_hex\n 0x1A\n \n \n krblastpwdchange\n \n 20140221175325Z\n \n \n \n \n \n \n \n Keytab successfully retrieved and stored in: /etc/krb5.keytab Certificate subject base is: O=BOINGO.COM Enrolled in IPA realm BOINGO.COM Starting external process args=kdestroy Process finished, return code=0 stdout= stderr= Starting external process args=/usr/bin/kinit -k -t /etc/krb5.keytab host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=0 stdout= stderr= Backing up system configuration file '/etc/ipa/default.conf' -> Not backing up - '/etc/ipa/default.conf' doesn't exist Created /etc/ipa/default.conf importing all plugin modules in '/usr/lib/python2.7/dist-packages/ipalib/plugins'... importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/aci.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/automember.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/automount.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/baseldap.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/batch.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/config.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/delegation.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/dns.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/entitle.py' skipping plugin module ipalib.plugins.entitle: No module named rhsm.connection importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/group.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacrule.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvc.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvcgroup.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbactest.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/host.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/hostgroup.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/idrange.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/internal.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/kerberos.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/krbtpolicy.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/migration.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/misc.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/netgroup.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/passwd.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/permission.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/ping.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/pkinit.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/privilege.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/pwpolicy.py' Starting external process args=klist -V Process finished, return code=0 stdout=Kerberos 5 version 1.10-beta1 stderr= importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/realmdomains.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/role.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/selfservice.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/selinuxusermap.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/service.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmd.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmdgroup.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudorule.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/trust.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/user.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/virtual.py' importing plugin module '/usr/lib/python2.7/dist-packages/ipalib/plugins/xmlclient.py' Backing up system configuration file '/etc/sssd/sssd.conf' Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' Domain boingo.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf Starting external process args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt Process finished, return code=0 stdout= stderr= Backing up system configuration file '/etc/krb5.conf' Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' Writing Kerberos configuration to /etc/krb5.conf: #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = BOINGO.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] BOINGO.COM = { kdc = se-idm-01.boingo.com:88 master_kdc = se-idm-01.boingo.com:88 admin_server = se-idm-01.boingo.com:749 default_domain = boingo.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .boingo.com = BOINGO.COM boingo.com = BOINGO.COM Configured /etc/krb5.conf for IPA realm BOINGO.COM Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available failed to find session_cookie in persistent storage for principal 'host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM' trying https://se-idm-01.boingo.com/ipa/xml Created connection context.xmlclient raw: env(None, server=True) env(None, server=True, all=True) Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' NSSConnection init se-idm-01.boingo.com Connecting: 66.103.90.130:0 auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 10 (0xa) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=BOINGO.COM Validity: Not Before: Wed Jan 22 23:22:58 2014 UTC Not After : Sat Jan 23 23:22:58 2016 UTC Subject: CN=se-idm-01.boingo.com,O=BOINGO.COM Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: da:61:36:ca:15:d7:7f:e1:8d:6d:8b:16:f1:36:66:db: 52:77:cb:54:45:24:70:ec:fb:f7:e9:3b:65:e3:39:65: fe:56:90:8c:f6:6c:da:2c:7e:e4:96:6d:f8:60:57:02: 93:db:91:7e:96:d1:03:03:34:ab:0a:90:39:6d:8a:e0: 92:a1:1c:62:3c:61:24:51:b8:e0:87:96:5f:a0:24:85: 2b:c5:43:4e:52:fd:a8:f9:28:25:00:84:53:31:51:e0: 01:02:57:3d:48:26:b4:99:c4:aa:5a:51:36:f6:0f:14: b2:ad:f1:15:10:05:86:ee:d1:d0:32:5b:c4:7b:4c:db: 82:28:3d:62:36:43:e0:c3:7b:ed:c9:b9:c4:58:34:a1: be:c5:1e:c0:b6:c7:9c:5b:1e:1d:48:b6:22:41:0e:e2: 4f:43:e0:1b:e2:64:f4:57:69:67:10:64:04:7a:a4:0a: 73:c5:6e:39:28:0b:76:9b:2b:b8:36:6a:59:e3:5e:84: 50:ce:b6:e3:19:43:c0:f4:85:02:81:39:74:91:f5:22: 04:c3:1f:49:64:39:b9:29:64:de:c4:69:76:56:a1:78: 58:fd:33:28:62:77:1f:4a:3f:9d:8d:11:d2:00:0a:c0: 73:1f:4f:42:89:26:a5:f2:93:a3:07:ef:3e:80:50:45 Exponent: 65537 (0x10001) Signed Extensions: (5) Name: Certificate Authority Key Identifier Critical: False Key ID: 2e:77:3e:6b:23:1f:b1:ce:07:8c:9e:09:09:03:cf:7c: 9a:20:46:cd Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Subject Key ID Critical: False Data: c5:83:cc:e3:c4:64:6f:f1:67:47:f3:cd:6a:bd:f5:2c: ac:91:1e:0c Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: b1:5d:69:6a:52:2a:42:4c:f7:4c:1e:f5:6e:4c:87:30: f5:f5:ab:9c:ad:e5:7e:8c:e1:54:95:1d:53:56:8f:8f: fc:a7:de:f2:61:f7:cd:a9:79:a7:a2:53:dd:8d:19:89: ce:fb:92:bb:ca:d7:4f:84:e2:63:9b:b6:b6:a0:aa:24: 10:ac:7c:ce:17:09:d1:4e:2a:8e:ae:55:fc:0a:11:52: ab:23:8b:25:85:15:3c:f3:bb:0a:51:11:4f:fc:87:e1: 0e:ca:12:cc:15:d4:36:57:a8:a4:db:42:0e:d1:1e:dc: 1f:64:33:34:da:58:4d:a6:39:ff:b5:2c:50:6c:99:67: ff:af:c0:65:d1:f6:d9:33:d5:a8:c9:9c:e3:6e:fa:b7: 96:09:cd:73:eb:80:21:7d:04:af:ce:fb:76:d8:b1:ef: b0:23:50:85:1c:34:9c:a2:9c:d7:c2:fd:0d:f0:bd:1f: 98:ec:19:03:00:47:17:9b:a2:1d:09:3f:04:3c:59:4c: 81:51:38:f0:e8:1e:74:49:5e:76:a1:d6:9a:9b:3d:fe: 85:12:37:6b:3f:c7:a7:62:ce:ea:68:d8:ff:47:5a:74: 41:ab:ea:0c:6a:35:e9:57:a6:3b:1f:c9:e1:12:87:8b: 81:eb:c4:73:c8:a9:4d:88:a9:40:22:f9:66:06:70:b4 Fingerprint (MD5): 43:6b:f7:a8:12:d6:72:2f:3c:36:60:ff:ea:6b:53:a9 Fingerprint (SHA1): 91:b6:61:43:5d:0b:d0:14:cf:71:c8:c6:20:88:74:be: ce:ad:a0:53 approved_usage = SSLServer intended_usage = SSLServer cert valid True for "CN=se-idm-01.boingo.com,O=BOINGO.COM" handshake complete, peer = 66.103.90.130:443 received Set-Cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 19:47:41 GMT; Secure; HttpOnly' storing cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 19:47:41 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s Process finished, return code=0 stdout=546101869 stderr= Hostname (se-idm-ubuntu-client-01.boingo.com) not found in DNS Writing nsupdate commands to /etc/ipa/.dns_update.txt: zone boingo.com. update delete se-idm-ubuntu-client-01.boingo.com. IN A send update add se-idm-ubuntu-client-01.boingo.com. 1200 IN A 23.253.21.58 send Starting external process args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt Process finished, return code=1 stdout= stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 Failed to update DNS records. Starting external process args=/usr/sbin/service dbus status Process finished, return code=0 stdout=dbus start/running, process 1004 stderr= Starting external process args=/usr/sbin/service certmonger restart Process finished, return code=0 stdout=certmonger stop/waiting certmonger start/running stderr= Starting external process args=/usr/sbin/service certmonger status Process finished, return code=0 stdout=certmonger start/running stderr= Starting external process args=/usr/sbin/service certmonger stop Process finished, return code=0 stdout=certmonger stop/waiting stderr= certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Starting external process args=/usr/sbin/service certmonger restart Process finished, return code=0 stdout=certmonger start/running stderr=stop: Unknown instance: Starting external process args=/usr/sbin/service certmonger status Process finished, return code=0 stdout=certmonger start/running stderr= Starting external process args=ipa-getcert request -d /etc/pki/nssdb -n IPA Machine Certificate - se-idm-ubuntu-client-01.boingo.com -N CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM -K host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout=Certificate at same location is already used by request with nickname "20140221175328". stderr= certmonger request for host certificate failed Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub raw: host_mod(u'se-idm-ubuntu-client-01.boingo.com', ipasshpubkey=[u'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv root at 1204base', u'ssh-dss AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= root at 1204base', u'ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= root at 1204base'], updatedns=False) host_mod(u'se-idm-ubuntu-client-01.boingo.com', random=False, ipasshpubkey=(u'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv root at 1204base', u'ssh-dss AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= root at 1204base', u'ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= root at 1204base'), rights=False, updatedns=False, all=False, raw=False) Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' NSSConnection init se-idm-01.boingo.com Connecting: 66.103.90.130:0 handshake complete, peer = 66.103.90.130:443 received Set-Cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 19:47:43 GMT; Secure; HttpOnly' storing cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 19:47:43 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s Process finished, return code=0 stdout=1008872903 stderr= Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no modifications to be performed Starting external process args=/usr/sbin/service nscd status Process finished, return code=1 stdout= stderr=nscd: unrecognized service Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Fri Feb 21 19:50:40 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 21 Feb 2014 14:50:40 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> Message-ID: <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> D'oh! I'm blaming Friday. Didn't think to heck. Will try Monday. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Feb 21, 2014, at 2:13 PM, Mauricio Tavares wrote: > > On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman > wrote: >> Bizarre. >> >> # strace -f -o /tmp/out ipa help >> >> Usage: ipa [global-options] COMMAND [command-options] >> >> : >> >> : >> >> : >> >> >> # ipa help >> >> Connection to ipamaster closed. >> >> $ > When you logged back in, did /tmp/out have anything interesting? >> >> >> >>> On 02/21/2014 01:36 PM, Rob Crittenden wrote: >>> >>> Bret Wortman wrote: >>>> >>>> I'm getting ready to leave for the weekend, and this isn't the kind of >>>> thing I want to track down on a Friday, but if anyone has any ideas for >>>> things I should look at come Monday morning, I'd be very appreciative. >>>> >>>> I've got a system with 12 replicas, and no matter which IPA server I log >>>> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >>>> session terminated. I also tried from a client system that has the >>>> ipatools rpm installed, and in that case I got bounced out of my sudo'd >>>> root session. >>>> >>>> I need to figure this out because something's obviously amiss, and we >>>> have discovered a number of systems that are lacking Kerberos keys. I >>>> was hoping the CLI would provide the mechanism to get them fixed. We're >>>> also trying to track down a 6-10 second delay every time a user logs in >>>> using SSSD to authenticate; the password check passes almost instantly, >>>> but something is taking up an additional bunch of time and my users are >>>> starting to complain. So I need to get past this so I can debug that. >>>> >>>> Thanks, and have a great weekend, all. >>> >>> >>> For the life of me I can't figure out what the ipa command might do that >>> would log you out. I think brute force might be a way to go with this: >>> >>> strace -f o /tmp/out ipa help >>> >>> Then go back in and see what happened. >>> >>> As for login delay you may want to pick a client system and bump up the >>> sssd debug level and see if that provides any clues. >>> >>> rob >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From rcritten at redhat.com Fri Feb 21 19:57:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 14:57:10 -0500 Subject: [Freeipa-users] Ubuntu Client HELL In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local> Message-ID: <5307AF96.1090903@redhat.com> Todd Maugh wrote: > IM in limbo here trying to solve this issue It would help if you said what issue you were having... And what version of the client you are running. Trolling through the log I see a couple of things: ntpdate failed, but that can happen if you already have ntpd configured on your client. We have a ticket open on that. The DNS update failed, presumably because you aren't using IPA for DNS. Not a big deal. The certmonger failure is due to a bad uninstall in the past. It is still tracking an old cert. You can clear it with: # ipa-getcert list # ipa-getcert stop-tracking -i The SSH keys are failing to load because they already exist in the host entry. I guess it was pre-created, or left over from a previous attempt? It doesn't appear to be a fatal error. rob > > here is my out put with the debug > > root at se-idm-ubuntu-client-01:/var/lib/ipa-client/sysrestore# > ipa-client-install -d --no-dns-sshfp > --hostname=se-idm-ubuntu-client-01.boingo.com --force-join > --domain=boingo.com --server=se-idm-01.boingo.com > /usr/sbin/ipa-client-install was invoked with options: {'domain': > 'boingo.com', 'force': False, 'krb5_offline_passwords': True, 'primary': > False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': False, > 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': > None, 'ca_cert_file': None, 'principal': None, 'keytab': None, > 'hostname': 'se-idm-ubuntu-client-01.boingo.com', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': > False, 'mkhomedir': False, 'conf_ssh': True, 'force_join': True, > 'server': ['se-idm-01.boingo.com'], 'prompt_password': False, 'permit': > False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > WARNING: ntpd time&date synchronization service will not be configured as > conflicting service (chronyd) is enabled > Use --force-ntpd option to disable it and force configuration of ntpd > > [IPA Discovery] > Starting IPA discovery with domain=boingo.com, > servers=['se-idm-01.boingo.com'], > hostname=se-idm-ubuntu-client-01.boingo.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.boingo.com > DNS record not found: NXDOMAIN > [LDAP server check] > Verifying that se-idm-01.boingo.com (realm None) is an IPA server > Init LDAP connection to: se-idm-01.boingo.com > Search LDAP server for IPA base DN > Check if naming context 'dc=boingo,dc=com' is for IPA > Naming context 'dc=boingo,dc=com' is a valid IPA context > Search for (objectClass=krbRealmContainer) in dc=boingo,dc=com (sub) > Found: cn=BOINGO.COM,cn=kerberos,dc=boingo,dc=com > Discovery result: Success; server=se-idm-01.boingo.com, > domain=boingo.com, kdc=None, basedn=dc=boingo,dc=com > Validated servers: se-idm-01.boingo.com > will use discovered domain: boingo.com > Using servers from command line, disabling DNS discovery > will use provided server: se-idm-01.boingo.com > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to > always access the discovered server for all operations and will not fail > over to other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no]: yes > will use discovered realm: BOINGO.COM > will use discovered basedn: dc=boingo,dc=com > Hostname: se-idm-ubuntu-client-01.boingo.com > Hostname source: Provided as option > Realm: BOINGO.COM > Realm source: Discovered from LDAP DNS records in se-idm-01.boingo.com > DNS Domain: boingo.com > DNS Domain source: Forced > IPA Server: se-idm-01.boingo.com > IPA Server source: Provided as option > BaseDN: dc=boingo,dc=com > BaseDN source: From IPA server ldap://se-idm-01.boingo.com:389 > > Continue to configure the system with these values? [no]: yes > Starting external process > args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r BOINGO.COM > Process finished, return code=0 > stdout= > stderr=Removing principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > > Removed old keys for realm BOINGO.COM from /etc/krb5.keytab > Starting external process > args=/bin/hostname se-idm-ubuntu-client-01.boingo.com > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/hostname' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > User authorized to enroll computers: admin > will use principal provided as option: admin > Synchronizing time with KDC... > Search DNS for SRV record of _ntp._udp.boingo.com > DNS record not found: NXDOMAIN > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > Writing Kerberos configuration to /tmp/tmpBuP7iE: > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = BOINGO.COM > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > BOINGO.COM = { > kdc = se-idm-01.boingo.com:88 > master_kdc = se-idm-01.boingo.com:88 > admin_server = se-idm-01.boingo.com:749 > default_domain = boingo.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .boingo.com = BOINGO.COM > boingo.com = BOINGO.COM > > Password for admin at BOINGO.COM: > Starting external process > args=kinit admin at BOINGO.COM > Process finished, return code=0 > stdout=Password for admin at BOINGO.COM: > > stderr= > trying to retrieve CA cert via LDAP from se-idm-01.boingo.com > flushing ldap://se-idm-01.boingo.com:389 from SchemaCache > retrieving schema for SchemaCache url=ldap://se-idm-01.boingo.com:389 > conn= > Existing CA cert and Retrieved CA cert are identical > Starting external process > args=/usr/sbin/ipa-join -s se-idm-01.boingo.com -b dc=boingo,dc=com -d > -h se-idm-ubuntu-client-01.boingo.com -f > Process finished, return code=0 > stdout= > stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > se-idm-ubuntu-client-01.boingo.com\r\n > \r\n > \r\n > nsosversion\r\n > 3.2.0-58-generic\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > XML-RPC RESPONSE: > > \n > \n > \n > \n > \n > fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n > \n > \n > sshpubkeyfp\n > \n > F9:63:24:7C:AF:AF:10:F8:1E:C2:16:69:FE:EF:57:18 > root at 1204base (ssh-dss)\n > 85:E8:4E:22:E6:7E:73:0D:10:5C:CB:1A:FC:8B:DE:5C > root at 1204base (ssh-rsa)\n > B8:BF:50:00:03:BF:AD:71:34:28:CE:83:0A:74:5E:8A > root at 1204base (ecdsa-sha2-nistp256)\n > \n > \n > \n > has_keytab\n > 1\n > \n > \n > ipasshpubkey\n > \n > ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base\n > ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base\n > ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base\n > \n > \n > \n > cn\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > usercertificate\n > \n > \n > MIIDqTCCApGgAwIBAgIBGjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpCT0lOR08uQ09NMR4w\n > HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTQwMjIxMTc1MzI5WhcNMTYwMjIyMTc1\n > MzI5WjBCMRMwEQYDVQQKEwpCT0lOR08uQ09NMSswKQYDVQQDEyJzZS1pZG0tdWJ1bnR1LWNsaWVu\n > dC0wMS5ib2luZ28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2f//2Wz6UwUp\n > EErhWDHE+maebFuN82TQnYoAkrDGkebMOmtbLIy8fa7BdY5VNf+bJrLZkoGVq5us9aTc+s1YX63P\n > rmbPjFbO8+vL9I8IVIUutkUTNEhpVm0xiFe+n6jF7OXnjo/sfYZ1zT2QUyLN3TMF97hU2+QBItuJ\n > XY7ChOWk++YeYjgPK0xkcjbMZkNGKxKFF1qURmZVvj0VLgUxX8UwwFQZZK2XEg1Iexa+4SsKhdJN\n > wNagw1x99CiUXChn7V4lYZe8Uk7QDalGrgQTCVAIT+/9IpR94H6N68bHYA/hdBmV1JshTrL2Uhr0\n > Z2eNSjv3bpHC7BqeyWLllLw55wIDAQABo4G2MIGzMB8GA1UdIwQYMBaAFC53PmsjH7HOB4yeCQkD\n > z3yaIEbNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL3NlLWlkbS0wMS5ib2lu\n > Z28uY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr\n > BgEFBQcDAjAdBgNVHQ4EFgQU7XOSHg+lb/Yizi5G81VQAT0VPQswDQYJKoZIhvcNAQELBQADggEB\n > AGL9mbEyxQSv9d1dbMIW1V4NOBOJFKYmEXKxuQtrOEUDTN7H7IGNm7grMgOMYzrLYs1ftRxXrySF\n > d8k/B3q8LBV2RQ7d0pT67cRH+YV6csmtpZ+YSOYSR+0e6F6BIsMCAU8lsjA7qvVYuaFCc+wvdiIp\n > rea4piqV+lxWp1m0b/mdFuCbLyXao+pr2F5JhCHueHnn14I3k+E78f07hQUccOuS0BELWo9chy+l\n > co7djPuzeG8MKTTr7+9L47dqhKhrY4sHyS+LhaUf3Y+irbLxgeqiBIjkV4TVkfZNZg4b6NvajgKM\n > L9bj5XRwrSAhv1YccwzE1GDOOrp2j3LRYIcEUok=\n > \n > \n > \n > \n > krbextradata\n > \n > \n > AAKVkgdTaG9zdC9zZS1pZG0tdWJ1bnR1LWNsaWVudC0wMS5ib2luZ28uY29tQEJPSU5HTy5DT00A\n > \n > \n > \n > \n > has_password\n > 0\n > \n > \n > subject\n > CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM\n > \n > \n > ipacertificatesubjectbase\n > \n > O=BOINGO.COM\n > \n > \n > \n > sha1_fingerprint\n > 60:5c:7f:f5:e7:77:b7:3c:0c:c8:c0:07:3f:c3:00:18:c1:dd:9d:af\n > \n > \n > krblastsuccessfulauth\n > \n > 20140221181453Z\n > \n > \n > \n > serial_number\n > 26\n > \n > \n > managedby_host\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > enrolledby_user\n > \n > admin\n > \n > \n > \n > dn\n > fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n > \n > \n > issuer\n > CN=Certificate Authority,O=BOINGO.COM\n > \n > \n > ipauniqueid\n > \n > 459b077c-9b20-11e3-89c9-782bcb03bc6d\n > \n > \n > \n > krbprincipalname\n > \n > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM\n > \n > \n > \n > serverhostname\n > \n > se-idm-ubuntu-client-01\n > \n > \n > \n > objectclass\n > \n > ipaobject\n > nshost\n > ipahost\n > pkiuser\n > ipaservice\n > krbprincipalaux\n > krbprincipal\n > ieee802device\n > ipasshhost\n > top\n > ipaSshGroupOfPubKeys\n > \n > \n > \n > valid_not_before\n > Fri Feb 21 17:53:29 2014 UTC\n > \n > \n > valid_not_after\n > Mon Feb 22 17:53:29 2016 UTC\n > \n > \n > fqdn\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > managing_host\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > md5_fingerprint\n > bb:dc:38:b3:19:ab:7c:07:27:31:f9:a7:78:a4:98:16\n > \n > \n > serial_number_hex\n > 0x1A\n > \n > \n > krblastpwdchange\n > \n > 20140221175325Z\n > \n > \n > \n > \n > \n > \n > \n > > Keytab successfully retrieved and stored in: /etc/krb5.keytab > Certificate subject base is: O=BOINGO.COM > > Enrolled in IPA realm BOINGO.COM > Starting external process > args=kdestroy > Process finished, return code=0 > stdout= > stderr= > Starting external process > args=/usr/bin/kinit -k -t /etc/krb5.keytab > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/ipa/default.conf' > -> Not backing up - '/etc/ipa/default.conf' doesn't exist > Created /etc/ipa/default.conf > importing all plugin modules in > '/usr/lib/python2.7/dist-packages/ipalib/plugins'... > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/aci.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automember.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automount.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/baseldap.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/batch.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/config.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/delegation.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/dns.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/entitle.py' > skipping plugin module ipalib.plugins.entitle: No module named > rhsm.connection > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/group.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacrule.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvc.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvcgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbactest.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/host.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hostgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/idrange.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/internal.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/kerberos.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/krbtpolicy.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/migration.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/misc.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/netgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/passwd.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/permission.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/ping.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pkinit.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/privilege.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pwpolicy.py' > Starting external process > args=klist -V > Process finished, return code=0 > stdout=Kerberos 5 version 1.10-beta1 > > stderr= > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/realmdomains.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/role.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selfservice.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selinuxusermap.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/service.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmd.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmdgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudorule.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/trust.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/user.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/virtual.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/xmlclient.py' > Backing up system configuration file '/etc/sssd/sssd.conf' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Domain boingo.com is already configured in existing SSSD config, > creating a new one. > The old /etc/sssd/sssd.conf is backed up and will be restored during > uninstall. > Configured /etc/sssd/sssd.conf > Starting external process > args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i > /etc/ipa/ca.crt > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/krb5.conf' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Writing Kerberos configuration to /etc/krb5.conf: > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = BOINGO.COM > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > BOINGO.COM = { > kdc = se-idm-01.boingo.com:88 > master_kdc = se-idm-01.boingo.com:88 > admin_server = se-idm-01.boingo.com:749 > default_domain = boingo.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .boingo.com = BOINGO.COM > boingo.com = BOINGO.COM > > Configured /etc/krb5.conf for IPA realm BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > failed to find session_cookie in persistent storage for principal > 'host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM' > trying https://se-idm-01.boingo.com/ipa/xml > Created connection context.xmlclient > raw: env(None, server=True) > env(None, server=True, all=True) > Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 10 (0xa) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=BOINGO.COM > Validity: > Not Before: Wed Jan 22 23:22:58 2014 UTC > Not After : Sat Jan 23 23:22:58 2016 UTC > Subject: CN=se-idm-01.boingo.com,O=BOINGO.COM > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > da:61:36:ca:15:d7:7f:e1:8d:6d:8b:16:f1:36:66:db: > 52:77:cb:54:45:24:70:ec:fb:f7:e9:3b:65:e3:39:65: > fe:56:90:8c:f6:6c:da:2c:7e:e4:96:6d:f8:60:57:02: > 93:db:91:7e:96:d1:03:03:34:ab:0a:90:39:6d:8a:e0: > 92:a1:1c:62:3c:61:24:51:b8:e0:87:96:5f:a0:24:85: > 2b:c5:43:4e:52:fd:a8:f9:28:25:00:84:53:31:51:e0: > 01:02:57:3d:48:26:b4:99:c4:aa:5a:51:36:f6:0f:14: > b2:ad:f1:15:10:05:86:ee:d1:d0:32:5b:c4:7b:4c:db: > 82:28:3d:62:36:43:e0:c3:7b:ed:c9:b9:c4:58:34:a1: > be:c5:1e:c0:b6:c7:9c:5b:1e:1d:48:b6:22:41:0e:e2: > 4f:43:e0:1b:e2:64:f4:57:69:67:10:64:04:7a:a4:0a: > 73:c5:6e:39:28:0b:76:9b:2b:b8:36:6a:59:e3:5e:84: > 50:ce:b6:e3:19:43:c0:f4:85:02:81:39:74:91:f5:22: > 04:c3:1f:49:64:39:b9:29:64:de:c4:69:76:56:a1:78: > 58:fd:33:28:62:77:1f:4a:3f:9d:8d:11:d2:00:0a:c0: > 73:1f:4f:42:89:26:a5:f2:93:a3:07:ef:3e:80:50:45 > Exponent: 65537 (0x10001) > Signed Extensions: (5) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 2e:77:3e:6b:23:1f:b1:ce:07:8c:9e:09:09:03:cf:7c: > 9a:20:46:cd > Serial Number: None > General Names: [0 total] > > Name: Authority Information Access > Critical: False > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > Name: Certificate Subject Key ID > Critical: False > Data: > c5:83:cc:e3:c4:64:6f:f1:67:47:f3:cd:6a:bd:f5:2c: > ac:91:1e:0c > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b1:5d:69:6a:52:2a:42:4c:f7:4c:1e:f5:6e:4c:87:30: > f5:f5:ab:9c:ad:e5:7e:8c:e1:54:95:1d:53:56:8f:8f: > fc:a7:de:f2:61:f7:cd:a9:79:a7:a2:53:dd:8d:19:89: > ce:fb:92:bb:ca:d7:4f:84:e2:63:9b:b6:b6:a0:aa:24: > 10:ac:7c:ce:17:09:d1:4e:2a:8e:ae:55:fc:0a:11:52: > ab:23:8b:25:85:15:3c:f3:bb:0a:51:11:4f:fc:87:e1: > 0e:ca:12:cc:15:d4:36:57:a8:a4:db:42:0e:d1:1e:dc: > 1f:64:33:34:da:58:4d:a6:39:ff:b5:2c:50:6c:99:67: > ff:af:c0:65:d1:f6:d9:33:d5:a8:c9:9c:e3:6e:fa:b7: > 96:09:cd:73:eb:80:21:7d:04:af:ce:fb:76:d8:b1:ef: > b0:23:50:85:1c:34:9c:a2:9c:d7:c2:fd:0d:f0:bd:1f: > 98:ec:19:03:00:47:17:9b:a2:1d:09:3f:04:3c:59:4c: > 81:51:38:f0:e8:1e:74:49:5e:76:a1:d6:9a:9b:3d:fe: > 85:12:37:6b:3f:c7:a7:62:ce:ea:68:d8:ff:47:5a:74: > 41:ab:ea:0c:6a:35:e9:57:a6:3b:1f:c9:e1:12:87:8b: > 81:eb:c4:73:c8:a9:4d:88:a9:40:22:f9:66:06:70:b4 > Fingerprint (MD5): > 43:6b:f7:a8:12:d6:72:2f:3c:36:60:ff:ea:6b:53:a9 > Fingerprint (SHA1): > 91:b6:61:43:5d:0b:d0:14:cf:71:c8:c6:20:88:74:be: > ce:ad:a0:53 > approved_usage = SSLServer intended_usage = SSLServer > cert valid True for "CN=se-idm-01.boingo.com,O=BOINGO.COM" > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:41 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:41 GMT; Secure; HttpOnly' for principal > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=546101869 > > stderr= > Hostname (se-idm-ubuntu-client-01.boingo.com) not found in DNS > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > > zone boingo.com. > update delete se-idm-ubuntu-client-01.boingo.com. IN A > send > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN A 23.253.21.58 > send > > Starting external process > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > Process finished, return code=1 > stdout= > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS > failure. Minor code may provide more information, Minor = Server > DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' > returned non-zero exit status 1 > Failed to update DNS records. > Starting external process > args=/usr/sbin/service dbus status > Process finished, return code=0 > stdout=dbus start/running, process 1004 > > stderr= > Starting external process > args=/usr/sbin/service certmonger restart > Process finished, return code=0 > stdout=certmonger stop/waiting > certmonger start/running > > stderr= > Starting external process > args=/usr/sbin/service certmonger status > Process finished, return code=0 > stdout=certmonger start/running > > stderr= > Starting external process > args=/usr/sbin/service certmonger stop > Process finished, return code=0 > stdout=certmonger stop/waiting > > stderr= > certmonger failed to stop: [Errno 2] No such file or directory: > '/var/run/ipa/services.list' > Starting external process > args=/usr/sbin/service certmonger restart > Process finished, return code=0 > stdout=certmonger start/running > > stderr=stop: Unknown instance: > > Starting external process > args=/usr/sbin/service certmonger status > Process finished, return code=0 > stdout=certmonger start/running > > stderr= > Starting external process > args=ipa-getcert request -d /etc/pki/nssdb -n IPA Machine Certificate - > se-idm-ubuntu-client-01.boingo.com -N > CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM -K > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout=Certificate at same location is already used by request with > nickname "20140221175328". > > stderr= > certmonger request for host certificate failed > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > raw: host_mod(u'se-idm-ubuntu-client-01.boingo.com', > ipasshpubkey=[u'ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base', u'ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base', u'ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base'], updatedns=False) > host_mod(u'se-idm-ubuntu-client-01.boingo.com', random=False, > ipasshpubkey=(u'ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base', u'ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base', u'ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base'), rights=False, updatedns=False, all=False, raw=False) > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:43 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:43 GMT; Secure; HttpOnly' for principal > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=1008872903 > > stderr= > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no > modifications to be performed > Starting external process > args=/usr/sbin/service nscd status > Process finished, return code=1 > stdout= > stderr=nscd: unrecognized service > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From tmaugh at boingo.com Fri Feb 21 20:07:37 2014 From: tmaugh at boingo.com (Todd Maugh) Date: Fri, 21 Feb 2014 20:07:37 +0000 Subject: [Freeipa-users] Ubuntu Client HELL In-Reply-To: <5307AF96.1090903@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local>, <5307AF96.1090903@redhat.com> Message-ID: <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> thanks Rob! the main issue I am having is that the install is not completing and setting this ubuntu host up as a client. I cleared out the old cert as you suggested, the ssh keys were copied over from a previous attempt. IM not using IPA as DNS and I understand the ntp part. so now my install finishes up like this: Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' NSSConnection init se-idm-01.boingo.com Connecting: 66.103.90.130:0 handshake complete, peer = 66.103.90.130:443 received Set-Cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' storing cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM Process finished, return code=1 stdout= stderr=keyctl_search: Required key not available Starting external process args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s Process finished, return code=0 stdout=700576616 stderr= Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no modifications to be performed Writing nsupdate commands to /etc/ipa/.dns_update.txt: zone boingo.com. update delete se-idm-ubuntu-client-01.boingo.com. IN SSHFP send update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 1 AD5C9E4F7AEA55418455D54D84862A2B6EC16AB4 update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 2 B1BE4E3E3B4A79CFFCE5B3BBCC31DFB9979F6A1D97EF4E3EF8F8295C2595033A update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 1 D456E5C237736406CB5F4B4C24C836217B6D977E update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 2 8125272934E18BFDDA77D5B03BBBF600A0833C37669C568A3476D623A191C457 update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 1 270551D349212B7112D4A9079FF490C8D6733041 update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 2 0BC5F5FA7155A03BD9B05DDD5882FD907A0FC8C6D6F6F3341521D4F7B57D3662 send Starting external process args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt Process finished, return code=1 stdout= stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 Could not update DNS SSHFP records. Starting external process args=/usr/sbin/service nscd status Process finished, return code=1 stdout= stderr=nscd: unrecognized service Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' thanks in advance for any help -Todd ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] Sent: Friday, February 21, 2014 11:57 AM To: freeipa-users Subject: Re: [Freeipa-users] Ubuntu Client HELL Todd Maugh wrote: > IM in limbo here trying to solve this issue It would help if you said what issue you were having... And what version of the client you are running. Trolling through the log I see a couple of things: ntpdate failed, but that can happen if you already have ntpd configured on your client. We have a ticket open on that. The DNS update failed, presumably because you aren't using IPA for DNS. Not a big deal. The certmonger failure is due to a bad uninstall in the past. It is still tracking an old cert. You can clear it with: # ipa-getcert list # ipa-getcert stop-tracking -i The SSH keys are failing to load because they already exist in the host entry. I guess it was pre-created, or left over from a previous attempt? It doesn't appear to be a fatal error. rob > > here is my out put with the debug > > root at se-idm-ubuntu-client-01:/var/lib/ipa-client/sysrestore# > ipa-client-install -d --no-dns-sshfp > --hostname=se-idm-ubuntu-client-01.boingo.com --force-join > --domain=boingo.com --server=se-idm-01.boingo.com > /usr/sbin/ipa-client-install was invoked with options: {'domain': > 'boingo.com', 'force': False, 'krb5_offline_passwords': True, 'primary': > False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': False, > 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': > None, 'ca_cert_file': None, 'principal': None, 'keytab': None, > 'hostname': 'se-idm-ubuntu-client-01.boingo.com', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': > False, 'mkhomedir': False, 'conf_ssh': True, 'force_join': True, > 'server': ['se-idm-01.boingo.com'], 'prompt_password': False, 'permit': > False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > WARNING: ntpd time&date synchronization service will not be configured as > conflicting service (chronyd) is enabled > Use --force-ntpd option to disable it and force configuration of ntpd > > [IPA Discovery] > Starting IPA discovery with domain=boingo.com, > servers=['se-idm-01.boingo.com'], > hostname=se-idm-ubuntu-client-01.boingo.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.boingo.com > DNS record not found: NXDOMAIN > [LDAP server check] > Verifying that se-idm-01.boingo.com (realm None) is an IPA server > Init LDAP connection to: se-idm-01.boingo.com > Search LDAP server for IPA base DN > Check if naming context 'dc=boingo,dc=com' is for IPA > Naming context 'dc=boingo,dc=com' is a valid IPA context > Search for (objectClass=krbRealmContainer) in dc=boingo,dc=com (sub) > Found: cn=BOINGO.COM,cn=kerberos,dc=boingo,dc=com > Discovery result: Success; server=se-idm-01.boingo.com, > domain=boingo.com, kdc=None, basedn=dc=boingo,dc=com > Validated servers: se-idm-01.boingo.com > will use discovered domain: boingo.com > Using servers from command line, disabling DNS discovery > will use provided server: se-idm-01.boingo.com > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to > always access the discovered server for all operations and will not fail > over to other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no]: yes > will use discovered realm: BOINGO.COM > will use discovered basedn: dc=boingo,dc=com > Hostname: se-idm-ubuntu-client-01.boingo.com > Hostname source: Provided as option > Realm: BOINGO.COM > Realm source: Discovered from LDAP DNS records in se-idm-01.boingo.com > DNS Domain: boingo.com > DNS Domain source: Forced > IPA Server: se-idm-01.boingo.com > IPA Server source: Provided as option > BaseDN: dc=boingo,dc=com > BaseDN source: From IPA server ldap://se-idm-01.boingo.com:389 > > Continue to configure the system with these values? [no]: yes > Starting external process > args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r BOINGO.COM > Process finished, return code=0 > stdout= > stderr=Removing principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > > Removed old keys for realm BOINGO.COM from /etc/krb5.keytab > Starting external process > args=/bin/hostname se-idm-ubuntu-client-01.boingo.com > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/hostname' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > User authorized to enroll computers: admin > will use principal provided as option: admin > Synchronizing time with KDC... > Search DNS for SRV record of _ntp._udp.boingo.com > DNS record not found: NXDOMAIN > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Starting external process > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com > Process finished, return code=1 > stdout= > stderr= > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > Writing Kerberos configuration to /tmp/tmpBuP7iE: > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = BOINGO.COM > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > BOINGO.COM = { > kdc = se-idm-01.boingo.com:88 > master_kdc = se-idm-01.boingo.com:88 > admin_server = se-idm-01.boingo.com:749 > default_domain = boingo.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .boingo.com = BOINGO.COM > boingo.com = BOINGO.COM > > Password for admin at BOINGO.COM: > Starting external process > args=kinit admin at BOINGO.COM > Process finished, return code=0 > stdout=Password for admin at BOINGO.COM: > > stderr= > trying to retrieve CA cert via LDAP from se-idm-01.boingo.com > flushing ldap://se-idm-01.boingo.com:389 from SchemaCache > retrieving schema for SchemaCache url=ldap://se-idm-01.boingo.com:389 > conn= > Existing CA cert and Retrieved CA cert are identical > Starting external process > args=/usr/sbin/ipa-join -s se-idm-01.boingo.com -b dc=boingo,dc=com -d > -h se-idm-ubuntu-client-01.boingo.com -f > Process finished, return code=0 > stdout= > stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > se-idm-ubuntu-client-01.boingo.com\r\n > \r\n > \r\n > nsosversion\r\n > 3.2.0-58-generic\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > XML-RPC RESPONSE: > > \n > \n > \n > \n > \n > fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n > \n > \n > sshpubkeyfp\n > \n > F9:63:24:7C:AF:AF:10:F8:1E:C2:16:69:FE:EF:57:18 > root at 1204base (ssh-dss)\n > 85:E8:4E:22:E6:7E:73:0D:10:5C:CB:1A:FC:8B:DE:5C > root at 1204base (ssh-rsa)\n > B8:BF:50:00:03:BF:AD:71:34:28:CE:83:0A:74:5E:8A > root at 1204base (ecdsa-sha2-nistp256)\n > \n > \n > \n > has_keytab\n > 1\n > \n > \n > ipasshpubkey\n > \n > ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base\n > ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base\n > ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base\n > \n > \n > \n > cn\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > usercertificate\n > \n > \n > MIIDqTCCApGgAwIBAgIBGjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpCT0lOR08uQ09NMR4w\n > HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTQwMjIxMTc1MzI5WhcNMTYwMjIyMTc1\n > MzI5WjBCMRMwEQYDVQQKEwpCT0lOR08uQ09NMSswKQYDVQQDEyJzZS1pZG0tdWJ1bnR1LWNsaWVu\n > dC0wMS5ib2luZ28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2f//2Wz6UwUp\n > EErhWDHE+maebFuN82TQnYoAkrDGkebMOmtbLIy8fa7BdY5VNf+bJrLZkoGVq5us9aTc+s1YX63P\n > rmbPjFbO8+vL9I8IVIUutkUTNEhpVm0xiFe+n6jF7OXnjo/sfYZ1zT2QUyLN3TMF97hU2+QBItuJ\n > XY7ChOWk++YeYjgPK0xkcjbMZkNGKxKFF1qURmZVvj0VLgUxX8UwwFQZZK2XEg1Iexa+4SsKhdJN\n > wNagw1x99CiUXChn7V4lYZe8Uk7QDalGrgQTCVAIT+/9IpR94H6N68bHYA/hdBmV1JshTrL2Uhr0\n > Z2eNSjv3bpHC7BqeyWLllLw55wIDAQABo4G2MIGzMB8GA1UdIwQYMBaAFC53PmsjH7HOB4yeCQkD\n > z3yaIEbNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL3NlLWlkbS0wMS5ib2lu\n > Z28uY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr\n > BgEFBQcDAjAdBgNVHQ4EFgQU7XOSHg+lb/Yizi5G81VQAT0VPQswDQYJKoZIhvcNAQELBQADggEB\n > AGL9mbEyxQSv9d1dbMIW1V4NOBOJFKYmEXKxuQtrOEUDTN7H7IGNm7grMgOMYzrLYs1ftRxXrySF\n > d8k/B3q8LBV2RQ7d0pT67cRH+YV6csmtpZ+YSOYSR+0e6F6BIsMCAU8lsjA7qvVYuaFCc+wvdiIp\n > rea4piqV+lxWp1m0b/mdFuCbLyXao+pr2F5JhCHueHnn14I3k+E78f07hQUccOuS0BELWo9chy+l\n > co7djPuzeG8MKTTr7+9L47dqhKhrY4sHyS+LhaUf3Y+irbLxgeqiBIjkV4TVkfZNZg4b6NvajgKM\n > L9bj5XRwrSAhv1YccwzE1GDOOrp2j3LRYIcEUok=\n > \n > \n > \n > \n > krbextradata\n > \n > \n > AAKVkgdTaG9zdC9zZS1pZG0tdWJ1bnR1LWNsaWVudC0wMS5ib2luZ28uY29tQEJPSU5HTy5DT00A\n > \n > \n > \n > \n > has_password\n > 0\n > \n > \n > subject\n > CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM\n > \n > \n > ipacertificatesubjectbase\n > \n > O=BOINGO.COM\n > \n > \n > \n > sha1_fingerprint\n > 60:5c:7f:f5:e7:77:b7:3c:0c:c8:c0:07:3f:c3:00:18:c1:dd:9d:af\n > \n > \n > krblastsuccessfulauth\n > \n > 20140221181453Z\n > \n > \n > \n > serial_number\n > 26\n > \n > \n > managedby_host\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > enrolledby_user\n > \n > admin\n > \n > \n > \n > dn\n > fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n > \n > \n > issuer\n > CN=Certificate Authority,O=BOINGO.COM\n > \n > \n > ipauniqueid\n > \n > 459b077c-9b20-11e3-89c9-782bcb03bc6d\n > \n > \n > \n > krbprincipalname\n > \n > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM\n > \n > \n > \n > serverhostname\n > \n > se-idm-ubuntu-client-01\n > \n > \n > \n > objectclass\n > \n > ipaobject\n > nshost\n > ipahost\n > pkiuser\n > ipaservice\n > krbprincipalaux\n > krbprincipal\n > ieee802device\n > ipasshhost\n > top\n > ipaSshGroupOfPubKeys\n > \n > \n > \n > valid_not_before\n > Fri Feb 21 17:53:29 2014 UTC\n > \n > \n > valid_not_after\n > Mon Feb 22 17:53:29 2016 UTC\n > \n > \n > fqdn\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > managing_host\n > \n > se-idm-ubuntu-client-01.boingo.com\n > \n > \n > \n > md5_fingerprint\n > bb:dc:38:b3:19:ab:7c:07:27:31:f9:a7:78:a4:98:16\n > \n > \n > serial_number_hex\n > 0x1A\n > \n > \n > krblastpwdchange\n > \n > 20140221175325Z\n > \n > \n > \n > \n > \n > \n > \n > > Keytab successfully retrieved and stored in: /etc/krb5.keytab > Certificate subject base is: O=BOINGO.COM > > Enrolled in IPA realm BOINGO.COM > Starting external process > args=kdestroy > Process finished, return code=0 > stdout= > stderr= > Starting external process > args=/usr/bin/kinit -k -t /etc/krb5.keytab > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/ipa/default.conf' > -> Not backing up - '/etc/ipa/default.conf' doesn't exist > Created /etc/ipa/default.conf > importing all plugin modules in > '/usr/lib/python2.7/dist-packages/ipalib/plugins'... > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/aci.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automember.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automount.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/baseldap.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/batch.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/config.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/delegation.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/dns.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/entitle.py' > skipping plugin module ipalib.plugins.entitle: No module named > rhsm.connection > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/group.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacrule.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvc.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvcgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbactest.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/host.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hostgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/idrange.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/internal.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/kerberos.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/krbtpolicy.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/migration.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/misc.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/netgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/passwd.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/permission.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/ping.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pkinit.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/privilege.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pwpolicy.py' > Starting external process > args=klist -V > Process finished, return code=0 > stdout=Kerberos 5 version 1.10-beta1 > > stderr= > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/realmdomains.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/role.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selfservice.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selinuxusermap.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/service.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmd.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmdgroup.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudorule.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/trust.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/user.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/virtual.py' > importing plugin module > '/usr/lib/python2.7/dist-packages/ipalib/plugins/xmlclient.py' > Backing up system configuration file '/etc/sssd/sssd.conf' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Domain boingo.com is already configured in existing SSSD config, > creating a new one. > The old /etc/sssd/sssd.conf is backed up and will be restored during > uninstall. > Configured /etc/sssd/sssd.conf > Starting external process > args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i > /etc/ipa/ca.crt > Process finished, return code=0 > stdout= > stderr= > Backing up system configuration file '/etc/krb5.conf' > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > Writing Kerberos configuration to /etc/krb5.conf: > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = BOINGO.COM > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > BOINGO.COM = { > kdc = se-idm-01.boingo.com:88 > master_kdc = se-idm-01.boingo.com:88 > admin_server = se-idm-01.boingo.com:749 > default_domain = boingo.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .boingo.com = BOINGO.COM > boingo.com = BOINGO.COM > > Configured /etc/krb5.conf for IPA realm BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > failed to find session_cookie in persistent storage for principal > 'host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM' > trying https://se-idm-01.boingo.com/ipa/xml > Created connection context.xmlclient > raw: env(None, server=True) > env(None, server=True, all=True) > Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 10 (0xa) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=BOINGO.COM > Validity: > Not Before: Wed Jan 22 23:22:58 2014 UTC > Not After : Sat Jan 23 23:22:58 2016 UTC > Subject: CN=se-idm-01.boingo.com,O=BOINGO.COM > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > da:61:36:ca:15:d7:7f:e1:8d:6d:8b:16:f1:36:66:db: > 52:77:cb:54:45:24:70:ec:fb:f7:e9:3b:65:e3:39:65: > fe:56:90:8c:f6:6c:da:2c:7e:e4:96:6d:f8:60:57:02: > 93:db:91:7e:96:d1:03:03:34:ab:0a:90:39:6d:8a:e0: > 92:a1:1c:62:3c:61:24:51:b8:e0:87:96:5f:a0:24:85: > 2b:c5:43:4e:52:fd:a8:f9:28:25:00:84:53:31:51:e0: > 01:02:57:3d:48:26:b4:99:c4:aa:5a:51:36:f6:0f:14: > b2:ad:f1:15:10:05:86:ee:d1:d0:32:5b:c4:7b:4c:db: > 82:28:3d:62:36:43:e0:c3:7b:ed:c9:b9:c4:58:34:a1: > be:c5:1e:c0:b6:c7:9c:5b:1e:1d:48:b6:22:41:0e:e2: > 4f:43:e0:1b:e2:64:f4:57:69:67:10:64:04:7a:a4:0a: > 73:c5:6e:39:28:0b:76:9b:2b:b8:36:6a:59:e3:5e:84: > 50:ce:b6:e3:19:43:c0:f4:85:02:81:39:74:91:f5:22: > 04:c3:1f:49:64:39:b9:29:64:de:c4:69:76:56:a1:78: > 58:fd:33:28:62:77:1f:4a:3f:9d:8d:11:d2:00:0a:c0: > 73:1f:4f:42:89:26:a5:f2:93:a3:07:ef:3e:80:50:45 > Exponent: 65537 (0x10001) > Signed Extensions: (5) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 2e:77:3e:6b:23:1f:b1:ce:07:8c:9e:09:09:03:cf:7c: > 9a:20:46:cd > Serial Number: None > General Names: [0 total] > > Name: Authority Information Access > Critical: False > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > Name: Certificate Subject Key ID > Critical: False > Data: > c5:83:cc:e3:c4:64:6f:f1:67:47:f3:cd:6a:bd:f5:2c: > ac:91:1e:0c > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b1:5d:69:6a:52:2a:42:4c:f7:4c:1e:f5:6e:4c:87:30: > f5:f5:ab:9c:ad:e5:7e:8c:e1:54:95:1d:53:56:8f:8f: > fc:a7:de:f2:61:f7:cd:a9:79:a7:a2:53:dd:8d:19:89: > ce:fb:92:bb:ca:d7:4f:84:e2:63:9b:b6:b6:a0:aa:24: > 10:ac:7c:ce:17:09:d1:4e:2a:8e:ae:55:fc:0a:11:52: > ab:23:8b:25:85:15:3c:f3:bb:0a:51:11:4f:fc:87:e1: > 0e:ca:12:cc:15:d4:36:57:a8:a4:db:42:0e:d1:1e:dc: > 1f:64:33:34:da:58:4d:a6:39:ff:b5:2c:50:6c:99:67: > ff:af:c0:65:d1:f6:d9:33:d5:a8:c9:9c:e3:6e:fa:b7: > 96:09:cd:73:eb:80:21:7d:04:af:ce:fb:76:d8:b1:ef: > b0:23:50:85:1c:34:9c:a2:9c:d7:c2:fd:0d:f0:bd:1f: > 98:ec:19:03:00:47:17:9b:a2:1d:09:3f:04:3c:59:4c: > 81:51:38:f0:e8:1e:74:49:5e:76:a1:d6:9a:9b:3d:fe: > 85:12:37:6b:3f:c7:a7:62:ce:ea:68:d8:ff:47:5a:74: > 41:ab:ea:0c:6a:35:e9:57:a6:3b:1f:c9:e1:12:87:8b: > 81:eb:c4:73:c8:a9:4d:88:a9:40:22:f9:66:06:70:b4 > Fingerprint (MD5): > 43:6b:f7:a8:12:d6:72:2f:3c:36:60:ff:ea:6b:53:a9 > Fingerprint (SHA1): > 91:b6:61:43:5d:0b:d0:14:cf:71:c8:c6:20:88:74:be: > ce:ad:a0:53 > approved_usage = SSLServer intended_usage = SSLServer > cert valid True for "CN=se-idm-01.boingo.com,O=BOINGO.COM" > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:41 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:41 GMT; Secure; HttpOnly' for principal > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=546101869 > > stderr= > Hostname (se-idm-ubuntu-client-01.boingo.com) not found in DNS > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > > zone boingo.com. > update delete se-idm-ubuntu-client-01.boingo.com. IN A > send > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN A 23.253.21.58 > send > > Starting external process > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > Process finished, return code=1 > stdout= > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS > failure. Minor code may provide more information, Minor = Server > DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' > returned non-zero exit status 1 > Failed to update DNS records. > Starting external process > args=/usr/sbin/service dbus status > Process finished, return code=0 > stdout=dbus start/running, process 1004 > > stderr= > Starting external process > args=/usr/sbin/service certmonger restart > Process finished, return code=0 > stdout=certmonger stop/waiting > certmonger start/running > > stderr= > Starting external process > args=/usr/sbin/service certmonger status > Process finished, return code=0 > stdout=certmonger start/running > > stderr= > Starting external process > args=/usr/sbin/service certmonger stop > Process finished, return code=0 > stdout=certmonger stop/waiting > > stderr= > certmonger failed to stop: [Errno 2] No such file or directory: > '/var/run/ipa/services.list' > Starting external process > args=/usr/sbin/service certmonger restart > Process finished, return code=0 > stdout=certmonger start/running > > stderr=stop: Unknown instance: > > Starting external process > args=/usr/sbin/service certmonger status > Process finished, return code=0 > stdout=certmonger start/running > > stderr= > Starting external process > args=ipa-getcert request -d /etc/pki/nssdb -n IPA Machine Certificate - > se-idm-ubuntu-client-01.boingo.com -N > CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM -K > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout=Certificate at same location is already used by request with > nickname "20140221175328". > > stderr= > certmonger request for host certificate failed > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > raw: host_mod(u'se-idm-ubuntu-client-01.boingo.com', > ipasshpubkey=[u'ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base', u'ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base', u'ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base'], updatedns=False) > host_mod(u'se-idm-ubuntu-client-01.boingo.com', random=False, > ipasshpubkey=(u'ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > root at 1204base', u'ssh-dss > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > root at 1204base', u'ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > root at 1204base'), rights=False, updatedns=False, all=False, raw=False) > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:43 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 > 19:47:43 GMT; Secure; HttpOnly' for principal > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=1008872903 > > stderr= > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no > modifications to be performed > Starting external process > args=/usr/sbin/service nscd status > Process finished, return code=1 > stdout= > stderr=nscd: unrecognized service > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From genadipost at gmail.com Fri Feb 21 21:17:38 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 21 Feb 2014 23:17:38 +0200 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: <1392997128.22754.323.camel@willson.li.ssimo.org> References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> <20140219083526.GD2781@localhost.localdomain> <1392997128.22754.323.camel@willson.li.ssimo.org> Message-ID: I would like to clarify myself, i wasn't accurate when i compared it to : https://bugzilla.redhat.com/show_bug.cgi?id=878564. I have tried to reproduce the bug by restarting the AD. *I was able to preform winbindd commands:* [root at ipaserver1 ~]# wbinfo -u ADEXAMPLE\administrator ADEXAMPLE\guest ADEXAMPLE\genadi ADEXAMPLE\krbtgt ADEXAMPLE\linux$ ADEXAMPLE\daniel [root at ipaserver1 ~]# wbinfo -g admins editors default smb group ad_users ADEXAMPLE\domain computers ADEXAMPLE\domain controllers ADEXAMPLE\schema admins ADEXAMPLE\enterprise admins ADEXAMPLE\domain admins ADEXAMPLE\domain users ADEXAMPLE\domain guests ADEXAMPLE\group policy creator owners ADEXAMPLE\read-only domain controllers ADEXAMPLE\enterprise read-only domain controllers ADEXAMPLE\dnsupdateproxy [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\administrator" S-1-5-21-2887728911-2909484380-3974070232-500 SID_USER (1) [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\guest" S-1-5-21-2887728911-2909484380-3974070232-501 SID_USER (1) [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\genadi" S-1-5-21-2887728911-2909484380-3974070232-1000 SID_USER (1) [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\krbtgt" S-1-5-21-2887728911-2909484380-3974070232-502 SID_USER (1) [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\linux$" S-1-5-21-2887728911-2909484380-3974070232-1104 SID_USER (1) [root at ipaserver1 ~]# wbinfo -n "ADEXAMPLE\daniel" S-1-5-21-2887728911-2909484380-3974070232-1105 SID_USER (1) *But kinit with AD users failed:* [root at ipaserver1 ~]# kinit Genadi at ADEXAMPLE.COM kinit: Cannot resolve servers for KDC in realm "ADEXAMPLE.COM" while getting initial credentials *But after few minutes i was able to to kinit with AD users agian:* [root at ipaserver1 ~]# kinit Genadi at ADEXAMPLE.COM Password for Genadi at ADEXAMPLE.COM: I think i was too fast on making conclusions. Not sure if opening a bug is needed. 2014-02-21 17:38 GMT+02:00 Simo Sorce : > On Fri, 2014-02-21 at 00:27 +0200, Genadi Postrilko wrote: > > Update: > > For some reason the AD server has rebooted himself. > > After the reboot i couldn't preform kinit with AD users. > > I found a bugzilla that describes the symptoms that i experienced : > > https://bugzilla.redhat.com/show_bug.cgi?id=878564 > > Not sure if it is the same bug - the bugzilla reports bug in > > samba4-4.0.0-48.el6.rc4.x86_64 > > while my version is samba4-4.0.0-58.el6.rc4.x86_64 (after downgrade). > > > > I have rebooted the IPA server to see if it changes anything. > > After the reboot i was able to kinit with AD users, but not only that - > now > > i am able to > > login with AD users to client machines. > > > > Any idea on what just happened? > > Sounds like a bug in windbindd which we currently use to talk to the > Windows DCs for this functionality. > Apparently winbindd failed to detect the DC came back online. > A restart of the ipa server caused winbindd to restart and retry to get > online. > > Can you please open a bug to track this issue ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Feb 21 21:47:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 21 Feb 2014 16:47:53 -0500 Subject: [Freeipa-users] Ubuntu Client HELL In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local>, <5307AF96.1090903@redhat.com> <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> Message-ID: <5307C989.207@redhat.com> On 02/21/2014 03:07 PM, Todd Maugh wrote: > thanks Rob! the main issue I am having is that the install is not completing and setting this ubuntu host up as a client. > > I cleared out the old cert as you suggested, the ssh keys were copied over from a previous attempt. IM not using IPA as DNS and I understand the ntp part. > > > so now my install finishes up like this: > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=700576616 > > stderr= > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no modifications to be performed > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > zone boingo.com. > update delete se-idm-ubuntu-client-01.boingo.com. IN SSHFP > send > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 1 AD5C9E4F7AEA55418455D54D84862A2B6EC16AB4 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 2 B1BE4E3E3B4A79CFFCE5B3BBCC31DFB9979F6A1D97EF4E3EF8F8295C2595033A > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 1 D456E5C237736406CB5F4B4C24C836217B6D977E > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 2 8125272934E18BFDDA77D5B03BBBF600A0833C37669C568A3476D623A191C457 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 1 270551D349212B7112D4A9079FF490C8D6733041 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 2 0BC5F5FA7155A03BD9B05DDD5882FD907A0FC8C6D6F6F3341521D4F7B57D3662 > send > > Starting external process > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > Process finished, return code=1 > stdout= > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 > Could not update DNS SSHFP records. > Starting external process > args=/usr/sbin/service nscd status > Process finished, return code=1 > stdout= > stderr=nscd: unrecognized service > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > > thanks in advance for any help > > -Todd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rob Crittenden [rcritten at redhat.com] > Sent: Friday, February 21, 2014 11:57 AM > To: freeipa-users > Subject: Re: [Freeipa-users] Ubuntu Client HELL > > Todd Maugh wrote: >> IM in limbo here trying to solve this issue > It would help if you said what issue you were having... > > And what version of the client you are running. > > Trolling through the log I see a couple of things: > > ntpdate failed, but that can happen if you already have ntpd configured > on your client. We have a ticket open on that. > > The DNS update failed, presumably because you aren't using IPA for DNS. > Not a big deal. > > The certmonger failure is due to a bad uninstall in the past. It is > still tracking an old cert. You can clear it with: > > # ipa-getcert list > # ipa-getcert stop-tracking -i > > The SSH keys are failing to load because they already exist in the host > entry. I guess it was pre-created, or left over from a previous attempt? > It doesn't appear to be a fatal error. > > rob > >> here is my out put with the debug >> >> root at se-idm-ubuntu-client-01:/var/lib/ipa-client/sysrestore# >> ipa-client-install -d --no-dns-sshfp >> --hostname=se-idm-ubuntu-client-01.boingo.com --force-join >> --domain=boingo.com --server=se-idm-01.boingo.com >> /usr/sbin/ipa-client-install was invoked with options: {'domain': >> 'boingo.com', 'force': False, 'krb5_offline_passwords': True, 'primary': >> False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': False, >> 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': >> None, 'ca_cert_file': None, 'principal': None, 'keytab': None, >> 'hostname': 'se-idm-ubuntu-client-01.boingo.com', 'no_ac': False, >> 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': >> False, 'mkhomedir': False, 'conf_ssh': True, 'force_join': True, >> 'server': ['se-idm-01.boingo.com'], 'prompt_password': False, 'permit': >> False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} >> missing options might be asked for interactively later >> Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' >> WARNING: ntpd time&date synchronization service will not be configured as >> conflicting service (chronyd) is enabled >> Use --force-ntpd option to disable it and force configuration of ntpd >> >> [IPA Discovery] >> Starting IPA discovery with domain=boingo.com, >> servers=['se-idm-01.boingo.com'], >> hostname=se-idm-ubuntu-client-01.boingo.com >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.boingo.com >> DNS record not found: NXDOMAIN >> [LDAP server check] >> Verifying that se-idm-01.boingo.com (realm None) is an IPA server >> Init LDAP connection to: se-idm-01.boingo.com >> Search LDAP server for IPA base DN >> Check if naming context 'dc=boingo,dc=com' is for IPA >> Naming context 'dc=boingo,dc=com' is a valid IPA context >> Search for (objectClass=krbRealmContainer) in dc=boingo,dc=com (sub) >> Found: cn=BOINGO.COM,cn=kerberos,dc=boingo,dc=com >> Discovery result: Success; server=se-idm-01.boingo.com, >> domain=boingo.com, kdc=None, basedn=dc=boingo,dc=com >> Validated servers: se-idm-01.boingo.com >> will use discovered domain: boingo.com >> Using servers from command line, disabling DNS discovery >> will use provided server: se-idm-01.boingo.com >> Autodiscovery of servers for failover cannot work with this configuration. >> If you proceed with the installation, services will be configured to >> always access the discovered server for all operations and will not fail >> over to other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no]: yes >> will use discovered realm: BOINGO.COM >> will use discovered basedn: dc=boingo,dc=com >> Hostname: se-idm-ubuntu-client-01.boingo.com >> Hostname source: Provided as option >> Realm: BOINGO.COM >> Realm source: Discovered from LDAP DNS records in se-idm-01.boingo.com >> DNS Domain: boingo.com >> DNS Domain source: Forced >> IPA Server: se-idm-01.boingo.com >> IPA Server source: Provided as option >> BaseDN: dc=boingo,dc=com >> BaseDN source: From IPA server ldap://se-idm-01.boingo.com:389 >> >> Continue to configure the system with these values? [no]: yes >> Starting external process >> args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r BOINGO.COM >> Process finished, return code=0 >> stdout= >> stderr=Removing principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> >> Removed old keys for realm BOINGO.COM from /etc/krb5.keytab >> Starting external process >> args=/bin/hostname se-idm-ubuntu-client-01.boingo.com >> Process finished, return code=0 >> stdout= >> stderr= >> Backing up system configuration file '/etc/hostname' >> Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' >> User authorized to enroll computers: admin >> will use principal provided as option: admin >> Synchronizing time with KDC... >> Search DNS for SRV record of _ntp._udp.boingo.com >> DNS record not found: NXDOMAIN >> Starting external process >> args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com >> Process finished, return code=1 >> stdout= >> stderr= >> Starting external process >> args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com >> Process finished, return code=1 >> stdout= >> stderr= >> Starting external process >> args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com >> Process finished, return code=1 >> stdout= >> stderr= >> Unable to sync time with IPA NTP server, assuming the time is in sync. >> Please check that 123 UDP port is opened. >> Writing Kerberos configuration to /tmp/tmpBuP7iE: >> #File modified by ipa-client-install >> >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> >> [libdefaults] >> default_realm = BOINGO.COM >> dns_lookup_realm = false >> dns_lookup_kdc = false >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> BOINGO.COM = { >> kdc = se-idm-01.boingo.com:88 >> master_kdc = se-idm-01.boingo.com:88 >> admin_server = se-idm-01.boingo.com:749 >> default_domain = boingo.com >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .boingo.com = BOINGO.COM >> boingo.com = BOINGO.COM >> >> Password for admin at BOINGO.COM: >> Starting external process >> args=kinit admin at BOINGO.COM >> Process finished, return code=0 >> stdout=Password for admin at BOINGO.COM: >> >> stderr= >> trying to retrieve CA cert via LDAP from se-idm-01.boingo.com >> flushing ldap://se-idm-01.boingo.com:389 from SchemaCache >> retrieving schema for SchemaCache url=ldap://se-idm-01.boingo.com:389 >> conn= >> Existing CA cert and Retrieved CA cert are identical >> Starting external process >> args=/usr/sbin/ipa-join -s se-idm-01.boingo.com -b dc=boingo,dc=com -d >> -h se-idm-ubuntu-client-01.boingo.com -f >> Process finished, return code=0 >> stdout= >> stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> se-idm-ubuntu-client-01.boingo.com\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 3.2.0-58-generic\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> XML-RPC RESPONSE: >> >> \n >> \n >> \n >> \n >> \n >> fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n >> \n >> \n >> sshpubkeyfp\n >> \n >> F9:63:24:7C:AF:AF:10:F8:1E:C2:16:69:FE:EF:57:18 >> root at 1204base (ssh-dss)\n >> 85:E8:4E:22:E6:7E:73:0D:10:5C:CB:1A:FC:8B:DE:5C >> root at 1204base (ssh-rsa)\n >> B8:BF:50:00:03:BF:AD:71:34:28:CE:83:0A:74:5E:8A >> root at 1204base (ecdsa-sha2-nistp256)\n >> \n >> \n >> \n >> has_keytab\n >> 1\n >> \n >> \n >> ipasshpubkey\n >> \n >> ssh-dss >> AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= >> root at 1204base\n >> ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv >> root at 1204base\n >> ecdsa-sha2-nistp256 >> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= >> root at 1204base\n >> \n >> \n >> \n >> cn\n >> \n >> se-idm-ubuntu-client-01.boingo.com\n >> \n >> \n >> \n >> usercertificate\n >> \n >> \n >> MIIDqTCCApGgAwIBAgIBGjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpCT0lOR08uQ09NMR4w\n >> HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTQwMjIxMTc1MzI5WhcNMTYwMjIyMTc1\n >> MzI5WjBCMRMwEQYDVQQKEwpCT0lOR08uQ09NMSswKQYDVQQDEyJzZS1pZG0tdWJ1bnR1LWNsaWVu\n >> dC0wMS5ib2luZ28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2f//2Wz6UwUp\n >> EErhWDHE+maebFuN82TQnYoAkrDGkebMOmtbLIy8fa7BdY5VNf+bJrLZkoGVq5us9aTc+s1YX63P\n >> rmbPjFbO8+vL9I8IVIUutkUTNEhpVm0xiFe+n6jF7OXnjo/sfYZ1zT2QUyLN3TMF97hU2+QBItuJ\n >> XY7ChOWk++YeYjgPK0xkcjbMZkNGKxKFF1qURmZVvj0VLgUxX8UwwFQZZK2XEg1Iexa+4SsKhdJN\n >> wNagw1x99CiUXChn7V4lYZe8Uk7QDalGrgQTCVAIT+/9IpR94H6N68bHYA/hdBmV1JshTrL2Uhr0\n >> Z2eNSjv3bpHC7BqeyWLllLw55wIDAQABo4G2MIGzMB8GA1UdIwQYMBaAFC53PmsjH7HOB4yeCQkD\n >> z3yaIEbNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL3NlLWlkbS0wMS5ib2lu\n >> Z28uY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr\n >> BgEFBQcDAjAdBgNVHQ4EFgQU7XOSHg+lb/Yizi5G81VQAT0VPQswDQYJKoZIhvcNAQELBQADggEB\n >> AGL9mbEyxQSv9d1dbMIW1V4NOBOJFKYmEXKxuQtrOEUDTN7H7IGNm7grMgOMYzrLYs1ftRxXrySF\n >> d8k/B3q8LBV2RQ7d0pT67cRH+YV6csmtpZ+YSOYSR+0e6F6BIsMCAU8lsjA7qvVYuaFCc+wvdiIp\n >> rea4piqV+lxWp1m0b/mdFuCbLyXao+pr2F5JhCHueHnn14I3k+E78f07hQUccOuS0BELWo9chy+l\n >> co7djPuzeG8MKTTr7+9L47dqhKhrY4sHyS+LhaUf3Y+irbLxgeqiBIjkV4TVkfZNZg4b6NvajgKM\n >> L9bj5XRwrSAhv1YccwzE1GDOOrp2j3LRYIcEUok=\n >> \n >> \n >> \n >> \n >> krbextradata\n >> \n >> \n >> AAKVkgdTaG9zdC9zZS1pZG0tdWJ1bnR1LWNsaWVudC0wMS5ib2luZ28uY29tQEJPSU5HTy5DT00A\n >> \n >> \n >> \n >> \n >> has_password\n >> 0\n >> \n >> \n >> subject\n >> CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM\n >> \n >> \n >> ipacertificatesubjectbase\n >> \n >> O=BOINGO.COM\n >> \n >> \n >> \n >> sha1_fingerprint\n >> 60:5c:7f:f5:e7:77:b7:3c:0c:c8:c0:07:3f:c3:00:18:c1:dd:9d:af\n >> \n >> \n >> krblastsuccessfulauth\n >> \n >> 20140221181453Z\n >> \n >> \n >> \n >> serial_number\n >> 26\n >> \n >> \n >> managedby_host\n >> \n >> se-idm-ubuntu-client-01.boingo.com\n >> \n >> \n >> \n >> enrolledby_user\n >> \n >> admin\n >> \n >> \n >> \n >> dn\n >> fqdn=se-idm-ubuntu-client-01.boingo.com,cn=computers,cn=accounts,dc=boingo,dc=com\n >> \n >> \n >> issuer\n >> CN=Certificate Authority,O=BOINGO.COM\n >> \n >> \n >> ipauniqueid\n >> \n >> 459b077c-9b20-11e3-89c9-782bcb03bc6d\n >> \n >> \n >> \n >> krbprincipalname\n >> \n >> host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM\n >> \n >> \n >> \n >> serverhostname\n >> \n >> se-idm-ubuntu-client-01\n >> \n >> \n >> \n >> objectclass\n >> \n >> ipaobject\n >> nshost\n >> ipahost\n >> pkiuser\n >> ipaservice\n >> krbprincipalaux\n >> krbprincipal\n >> ieee802device\n >> ipasshhost\n >> top\n >> ipaSshGroupOfPubKeys\n >> \n >> \n >> \n >> valid_not_before\n >> Fri Feb 21 17:53:29 2014 UTC\n >> \n >> \n >> valid_not_after\n >> Mon Feb 22 17:53:29 2016 UTC\n >> \n >> \n >> fqdn\n >> \n >> se-idm-ubuntu-client-01.boingo.com\n >> \n >> \n >> \n >> managing_host\n >> \n >> se-idm-ubuntu-client-01.boingo.com\n >> \n >> \n >> \n >> md5_fingerprint\n >> bb:dc:38:b3:19:ab:7c:07:27:31:f9:a7:78:a4:98:16\n >> \n >> \n >> serial_number_hex\n >> 0x1A\n >> \n >> \n >> krblastpwdchange\n >> \n >> 20140221175325Z\n >> \n >> \n >> \n >> \n >> \n >> \n >> \n >> >> Keytab successfully retrieved and stored in: /etc/krb5.keytab >> Certificate subject base is: O=BOINGO.COM >> >> Enrolled in IPA realm BOINGO.COM >> Starting external process >> args=kdestroy >> Process finished, return code=0 >> stdout= >> stderr= >> Starting external process >> args=/usr/bin/kinit -k -t /etc/krb5.keytab >> host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=0 >> stdout= >> stderr= >> Backing up system configuration file '/etc/ipa/default.conf' >> -> Not backing up - '/etc/ipa/default.conf' doesn't exist >> Created /etc/ipa/default.conf >> importing all plugin modules in >> '/usr/lib/python2.7/dist-packages/ipalib/plugins'... >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/aci.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/automember.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/automount.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/baseldap.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/batch.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/config.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/delegation.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/dns.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/entitle.py' >> skipping plugin module ipalib.plugins.entitle: No module named >> rhsm.connection >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/group.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacrule.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvc.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvcgroup.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbactest.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/host.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/hostgroup.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/idrange.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/internal.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/kerberos.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/krbtpolicy.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/migration.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/misc.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/netgroup.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/passwd.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/permission.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/ping.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/pkinit.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/privilege.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/pwpolicy.py' >> Starting external process >> args=klist -V >> Process finished, return code=0 >> stdout=Kerberos 5 version 1.10-beta1 >> >> stderr= >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/realmdomains.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/role.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/selfservice.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/selinuxusermap.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/service.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmd.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmdgroup.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudorule.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/trust.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/user.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/virtual.py' >> importing plugin module >> '/usr/lib/python2.7/dist-packages/ipalib/plugins/xmlclient.py' >> Backing up system configuration file '/etc/sssd/sssd.conf' >> Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Domain boingo.com is already configured in existing SSSD config, >> creating a new one. >> The old /etc/sssd/sssd.conf is backed up and will be restored during >> uninstall. >> Configured /etc/sssd/sssd.conf >> Starting external process >> args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i >> /etc/ipa/ca.crt >> Process finished, return code=0 >> stdout= >> stderr= >> Backing up system configuration file '/etc/krb5.conf' >> Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Writing Kerberos configuration to /etc/krb5.conf: >> #File modified by ipa-client-install >> >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> >> [libdefaults] >> default_realm = BOINGO.COM >> dns_lookup_realm = false >> dns_lookup_kdc = false >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> BOINGO.COM = { >> kdc = se-idm-01.boingo.com:88 >> master_kdc = se-idm-01.boingo.com:88 >> admin_server = se-idm-01.boingo.com:749 >> default_domain = boingo.com >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .boingo.com = BOINGO.COM >> boingo.com = BOINGO.COM >> >> Configured /etc/krb5.conf for IPA realm BOINGO.COM >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> failed to find session_cookie in persistent storage for principal >> 'host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM' >> trying https://se-idm-01.boingo.com/ipa/xml >> Created connection context.xmlclient >> raw: env(None, server=True) >> env(None, server=True, all=True) >> Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' >> NSSConnection init se-idm-01.boingo.com >> Connecting: 66.103.90.130:0 >> auth_certificate_callback: check_sig=True is_server=False >> Data: >> Version: 3 (0x2) >> Serial Number: 10 (0xa) >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: CN=Certificate Authority,O=BOINGO.COM >> Validity: >> Not Before: Wed Jan 22 23:22:58 2014 UTC >> Not After : Sat Jan 23 23:22:58 2016 UTC >> Subject: CN=se-idm-01.boingo.com,O=BOINGO.COM >> Subject Public Key Info: >> Public Key Algorithm: >> Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> da:61:36:ca:15:d7:7f:e1:8d:6d:8b:16:f1:36:66:db: >> 52:77:cb:54:45:24:70:ec:fb:f7:e9:3b:65:e3:39:65: >> fe:56:90:8c:f6:6c:da:2c:7e:e4:96:6d:f8:60:57:02: >> 93:db:91:7e:96:d1:03:03:34:ab:0a:90:39:6d:8a:e0: >> 92:a1:1c:62:3c:61:24:51:b8:e0:87:96:5f:a0:24:85: >> 2b:c5:43:4e:52:fd:a8:f9:28:25:00:84:53:31:51:e0: >> 01:02:57:3d:48:26:b4:99:c4:aa:5a:51:36:f6:0f:14: >> b2:ad:f1:15:10:05:86:ee:d1:d0:32:5b:c4:7b:4c:db: >> 82:28:3d:62:36:43:e0:c3:7b:ed:c9:b9:c4:58:34:a1: >> be:c5:1e:c0:b6:c7:9c:5b:1e:1d:48:b6:22:41:0e:e2: >> 4f:43:e0:1b:e2:64:f4:57:69:67:10:64:04:7a:a4:0a: >> 73:c5:6e:39:28:0b:76:9b:2b:b8:36:6a:59:e3:5e:84: >> 50:ce:b6:e3:19:43:c0:f4:85:02:81:39:74:91:f5:22: >> 04:c3:1f:49:64:39:b9:29:64:de:c4:69:76:56:a1:78: >> 58:fd:33:28:62:77:1f:4a:3f:9d:8d:11:d2:00:0a:c0: >> 73:1f:4f:42:89:26:a5:f2:93:a3:07:ef:3e:80:50:45 >> Exponent: 65537 (0x10001) >> Signed Extensions: (5) >> Name: Certificate Authority Key Identifier >> Critical: False >> Key ID: >> 2e:77:3e:6b:23:1f:b1:ce:07:8c:9e:09:09:03:cf:7c: >> 9a:20:46:cd >> Serial Number: None >> General Names: [0 total] >> >> Name: Authority Information Access >> Critical: False >> >> Name: Certificate Key Usage >> Critical: True >> Usages: >> Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> Name: Extended Key Usage >> Critical: False >> Usages: >> TLS Web Server Authentication Certificate >> TLS Web Client Authentication Certificate >> >> Name: Certificate Subject Key ID >> Critical: False >> Data: >> c5:83:cc:e3:c4:64:6f:f1:67:47:f3:cd:6a:bd:f5:2c: >> ac:91:1e:0c >> >> Signature: >> Signature Algorithm: >> Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Signature: >> b1:5d:69:6a:52:2a:42:4c:f7:4c:1e:f5:6e:4c:87:30: >> f5:f5:ab:9c:ad:e5:7e:8c:e1:54:95:1d:53:56:8f:8f: >> fc:a7:de:f2:61:f7:cd:a9:79:a7:a2:53:dd:8d:19:89: >> ce:fb:92:bb:ca:d7:4f:84:e2:63:9b:b6:b6:a0:aa:24: >> 10:ac:7c:ce:17:09:d1:4e:2a:8e:ae:55:fc:0a:11:52: >> ab:23:8b:25:85:15:3c:f3:bb:0a:51:11:4f:fc:87:e1: >> 0e:ca:12:cc:15:d4:36:57:a8:a4:db:42:0e:d1:1e:dc: >> 1f:64:33:34:da:58:4d:a6:39:ff:b5:2c:50:6c:99:67: >> ff:af:c0:65:d1:f6:d9:33:d5:a8:c9:9c:e3:6e:fa:b7: >> 96:09:cd:73:eb:80:21:7d:04:af:ce:fb:76:d8:b1:ef: >> b0:23:50:85:1c:34:9c:a2:9c:d7:c2:fd:0d:f0:bd:1f: >> 98:ec:19:03:00:47:17:9b:a2:1d:09:3f:04:3c:59:4c: >> 81:51:38:f0:e8:1e:74:49:5e:76:a1:d6:9a:9b:3d:fe: >> 85:12:37:6b:3f:c7:a7:62:ce:ea:68:d8:ff:47:5a:74: >> 41:ab:ea:0c:6a:35:e9:57:a6:3b:1f:c9:e1:12:87:8b: >> 81:eb:c4:73:c8:a9:4d:88:a9:40:22:f9:66:06:70:b4 >> Fingerprint (MD5): >> 43:6b:f7:a8:12:d6:72:2f:3c:36:60:ff:ea:6b:53:a9 >> Fingerprint (SHA1): >> 91:b6:61:43:5d:0b:d0:14:cf:71:c8:c6:20:88:74:be: >> ce:ad:a0:53 >> approved_usage = SSLServer intended_usage = SSLServer >> cert valid True for "CN=se-idm-01.boingo.com,O=BOINGO.COM" >> handshake complete, peer = 66.103.90.130:443 >> received Set-Cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; >> Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 >> 19:47:41 GMT; Secure; HttpOnly' >> storing cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; >> Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 >> 19:47:41 GMT; Secure; HttpOnly' for principal >> host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> Starting external process >> args=keyctl padd user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s >> Process finished, return code=0 >> stdout=546101869 >> >> stderr= >> Hostname (se-idm-ubuntu-client-01.boingo.com) not found in DNS >> Writing nsupdate commands to /etc/ipa/.dns_update.txt: >> >> zone boingo.com. >> update delete se-idm-ubuntu-client-01.boingo.com. IN A >> send >> update add se-idm-ubuntu-client-01.boingo.com. 1200 IN A 23.253.21.58 >> send >> >> Starting external process >> args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt >> Process finished, return code=1 >> stdout= >> stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS >> failure. Minor code may provide more information, Minor = Server >> DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. >> >> nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' >> returned non-zero exit status 1 >> Failed to update DNS records. >> Starting external process >> args=/usr/sbin/service dbus status >> Process finished, return code=0 >> stdout=dbus start/running, process 1004 >> >> stderr= >> Starting external process >> args=/usr/sbin/service certmonger restart >> Process finished, return code=0 >> stdout=certmonger stop/waiting >> certmonger start/running >> >> stderr= >> Starting external process >> args=/usr/sbin/service certmonger status >> Process finished, return code=0 >> stdout=certmonger start/running >> >> stderr= >> Starting external process >> args=/usr/sbin/service certmonger stop >> Process finished, return code=0 >> stdout=certmonger stop/waiting >> >> stderr= >> certmonger failed to stop: [Errno 2] No such file or directory: >> '/var/run/ipa/services.list' >> Starting external process >> args=/usr/sbin/service certmonger restart >> Process finished, return code=0 >> stdout=certmonger start/running >> >> stderr=stop: Unknown instance: >> >> Starting external process >> args=/usr/sbin/service certmonger status >> Process finished, return code=0 >> stdout=certmonger start/running >> >> stderr= >> Starting external process >> args=ipa-getcert request -d /etc/pki/nssdb -n IPA Machine Certificate - >> se-idm-ubuntu-client-01.boingo.com -N >> CN=se-idm-ubuntu-client-01.boingo.com,O=BOINGO.COM -K >> host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout=Certificate at same location is already used by request with >> nickname "20140221175328". >> >> stderr= >> certmonger request for host certificate failed >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> raw: host_mod(u'se-idm-ubuntu-client-01.boingo.com', >> ipasshpubkey=[u'ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv >> root at 1204base', u'ssh-dss >> AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= >> root at 1204base', u'ecdsa-sha2-nistp256 >> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= >> root at 1204base'], updatedns=False) >> host_mod(u'se-idm-ubuntu-client-01.boingo.com', random=False, >> ipasshpubkey=(u'ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv >> root at 1204base', u'ssh-dss >> AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= >> root at 1204base', u'ecdsa-sha2-nistp256 >> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= >> root at 1204base'), rights=False, updatedns=False, all=False, raw=False) >> Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' >> NSSConnection init se-idm-01.boingo.com >> Connecting: 66.103.90.130:0 >> handshake complete, peer = 66.103.90.130:443 >> received Set-Cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; >> Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 >> 19:47:43 GMT; Secure; HttpOnly' >> storing cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; >> Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 >> 19:47:43 GMT; Secure; HttpOnly' for principal >> host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> Starting external process >> args=keyctl search @s user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM >> Process finished, return code=1 >> stdout= >> stderr=keyctl_search: Required key not available >> >> Starting external process >> args=keyctl padd user >> ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s >> Process finished, return code=0 >> stdout=1008872903 >> >> stderr= >> Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no >> modifications to be performed >> Starting external process >> args=/usr/sbin/service nscd status >> Process finished, return code=1 >> stdout= >> stderr=nscd: unrecognized service >> >> Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' >> Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Does the host have the old kerberos key? If you go to the IPA UI for the host does it still show that the host has the key and the cert? I bet it is. Clean both. Or remove and recreate the host entry that might be even cleaner but you need to think about all the host membership entries that would be deleted with this operation so use caution. The whole situation points to the following: 1) Client system was once provisioned 2) System was reimaged/reprovisioned but the unistall did not complete or was not run or was run offline so server still thinks that the client is still around a healthy but old instance and its keys are gone. To clean this situation the host entry and related certs should be clean both on the client and server side. Do we have a how to about that? IMO it would be handy to have a HOWTO that would tell "What should one do to reinstall the client if you wiped client without doing anything on the server". -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mail at willsheldon.com Fri Feb 21 21:57:59 2014 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 21 Feb 2014 13:57:59 -0800 Subject: [Freeipa-users] Ubuntu Client HELL In-Reply-To: <5307C989.207@redhat.com> References: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local> <,> <5307AF96.1090903@redhat.com> <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> <5307C989.207@redhat.com> Message-ID: <8A03DC3D99FD4637A92C12066390D614@willsheldon.com> +1 for `ipa force-delete client` script. Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 1:47 PM, Dmitri Pal wrote: > On 02/21/2014 03:07 PM, Todd Maugh wrote: > > thanks Rob! the main issue I am having is that the install is not completing and setting this ubuntu host up as a client. > > > > I cleared out the old cert as you suggested, the ssh keys were copied over from a previous attempt. IM not using IPA as DNS and I understand the ntp part. > > > > > > so now my install finishes up like this: > > > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > > NSSConnection init se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > Connecting: 66.103.90.130:0 > > handshake complete, peer = 66.103.90.130:443 > > received Set-Cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com (http://se-idm-01.boingo.com); Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' > > storing cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > Starting external process > > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > Process finished, return code=1 > > stdout= > > stderr=keyctl_search: Required key not available > > > > Starting external process > > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > Process finished, return code=1 > > stdout= > > stderr=keyctl_search: Required key not available > > > > Starting external process > > args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) @s > > Process finished, return code=0 > > stdout=700576616 > > > > stderr= > > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no modifications to be performed > > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > > zone boingo.com (http://boingo.com). > > update delete se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). IN SSHFP > > send > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 1 1 AD5C9E4F7AEA55418455D54D84862A2B6EC16AB4 > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 1 2 B1BE4E3E3B4A79CFFCE5B3BBCC31DFB9979F6A1D97EF4E3EF8F8295C2595033A > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 2 1 D456E5C237736406CB5F4B4C24C836217B6D977E > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 2 2 8125272934E18BFDDA77D5B03BBBF600A0833C37669C568A3476D623A191C457 > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 3 1 270551D349212B7112D4A9079FF490C8D6733041 > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN SSHFP 3 2 0BC5F5FA7155A03BD9B05DDD5882FD907A0FC8C6D6F6F3341521D4F7B57D3662 > > send > > > > Starting external process > > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > > Process finished, return code=1 > > stdout= > > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ns-1454.awsdns-53.org at BOINGO.COM (mailto:ns-1454.awsdns-53.org at BOINGO.COM) not found in Kerberos database. > > > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 > > Could not update DNS SSHFP records. > > Starting external process > > args=/usr/sbin/service nscd status > > Process finished, return code=1 > > stdout= > > stderr=nscd: unrecognized service > > > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > > > > > > thanks in advance for any help > > > > -Todd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > From: freeipa-users-bounces at redhat.com (mailto:freeipa-users-bounces at redhat.com) [freeipa-users-bounces at redhat.com (mailto:freeipa-users-bounces at redhat.com)] on behalf of Rob Crittenden [rcritten at redhat.com (mailto:rcritten at redhat.com)] > > Sent: Friday, February 21, 2014 11:57 AM > > To: freeipa-users > > Subject: Re: [Freeipa-users] Ubuntu Client HELL > > > > Todd Maugh wrote: > > > IM in limbo here trying to solve this issue > > > > It would help if you said what issue you were having... > > > > And what version of the client you are running. > > > > Trolling through the log I see a couple of things: > > > > ntpdate failed, but that can happen if you already have ntpd configured > > on your client. We have a ticket open on that. > > > > The DNS update failed, presumably because you aren't using IPA for DNS. > > Not a big deal. > > > > The certmonger failure is due to a bad uninstall in the past. It is > > still tracking an old cert. You can clear it with: > > > > # ipa-getcert list > > # ipa-getcert stop-tracking -i > > > > The SSH keys are failing to load because they already exist in the host > > entry. I guess it was pre-created, or left over from a previous attempt? > > It doesn't appear to be a fatal error. > > > > rob > > > > > here is my out put with the debug > > > > > > root at se-idm-ubuntu-client-01:/var/lib/ipa-client/sysrestore# > > > ipa-client-install -d --no-dns-sshfp > > > --hostname=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) --force-join > > > --domain=boingo.com (http://boingo.com) --server=se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > /usr/sbin/ipa-client-install was invoked with options: {'domain': > > > 'boingo.com (http://boingo.com)', 'force': False, 'krb5_offline_passwords': True, 'primary': > > > False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': False, > > > 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': > > > None, 'ca_cert_file': None, 'principal': None, 'keytab': None, > > > 'hostname': 'se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)', 'no_ac': False, > > > 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': > > > False, 'mkhomedir': False, 'conf_ssh': True, 'force_join': True, > > > 'server': ['se-idm-01.boingo.com (http://se-idm-01.boingo.com)'], 'prompt_password': False, 'permit': > > > False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} > > > missing options might be asked for interactively later > > > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > > > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > WARNING: ntpd time&date synchronization service will not be configured as > > > conflicting service (chronyd) is enabled > > > Use --force-ntpd option to disable it and force configuration of ntpd > > > > > > [IPA Discovery] > > > Starting IPA discovery with domain=boingo.com (http://boingo.com), > > > servers=['se-idm-01.boingo.com (http://se-idm-01.boingo.com)'], > > > hostname=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) > > > Server and domain forced > > > [Kerberos realm search] > > > Search DNS for TXT record of _kerberos.boingo.com (http://_kerberos.boingo.com) > > > DNS record not found: NXDOMAIN > > > [LDAP server check] > > > Verifying that se-idm-01.boingo.com (http://se-idm-01.boingo.com) (realm None) is an IPA server > > > Init LDAP connection to: se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Search LDAP server for IPA base DN > > > Check if naming context 'dc=boingo,dc=com' is for IPA > > > Naming context 'dc=boingo,dc=com' is a valid IPA context > > > Search for (objectClass=krbRealmContainer) in dc=boingo,dc=com (sub) > > > Found: cn=BOINGO.COM,cn=kerberos,dc=boingo,dc=com > > > Discovery result: Success; server=se-idm-01.boingo.com (http://se-idm-01.boingo.com), > > > domain=boingo.com (http://boingo.com), kdc=None, basedn=dc=boingo,dc=com > > > Validated servers: se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > will use discovered domain: boingo.com (http://boingo.com) > > > Using servers from command line, disabling DNS discovery > > > will use provided server: se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Autodiscovery of servers for failover cannot work with this configuration. > > > If you proceed with the installation, services will be configured to > > > always access the discovered server for all operations and will not fail > > > over to other servers in case of failure. > > > Proceed with fixed values and no DNS discovery? [no]: yes > > > will use discovered realm: BOINGO.COM > > > will use discovered basedn: dc=boingo,dc=com > > > Hostname: se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) > > > Hostname source: Provided as option > > > Realm: BOINGO.COM > > > Realm source: Discovered from LDAP DNS records in se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > DNS Domain: boingo.com (http://boingo.com) > > > DNS Domain source: Forced > > > IPA Server: se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > IPA Server source: Provided as option > > > BaseDN: dc=boingo,dc=com > > > BaseDN source: From IPA server ldap://se-idm-01.boingo.com:389 (http://se-idm-01.boingo.com:389) > > > > > > Continue to configure the system with these values? [no]: yes > > > Starting external process > > > args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r BOINGO.COM > > > Process finished, return code=0 > > > stdout= > > > stderr=Removing principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > > > > Removed old keys for realm BOINGO.COM from /etc/krb5.keytab > > > Starting external process > > > args=/bin/hostname se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) > > > Process finished, return code=0 > > > stdout= > > > stderr= > > > Backing up system configuration file '/etc/hostname' > > > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > User authorized to enroll computers: admin > > > will use principal provided as option: admin > > > Synchronizing time with KDC... > > > Search DNS for SRV record of _ntp._udp.boingo.com (http://_ntp._udp.boingo.com) > > > DNS record not found: NXDOMAIN > > > Starting external process > > > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Process finished, return code=1 > > > stdout= > > > stderr= > > > Starting external process > > > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Process finished, return code=1 > > > stdout= > > > stderr= > > > Starting external process > > > args=/usr/sbin/ntpdate -s -b -v se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Process finished, return code=1 > > > stdout= > > > stderr= > > > Unable to sync time with IPA NTP server, assuming the time is in sync. > > > Please check that 123 UDP port is opened. > > > Writing Kerberos configuration to /tmp/tmpBuP7iE: > > > #File modified by ipa-client-install > > > > > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > > > > > [libdefaults] > > > default_realm = BOINGO.COM > > > dns_lookup_realm = false > > > dns_lookup_kdc = false > > > rdns = false > > > ticket_lifetime = 24h > > > forwardable = yes > > > > > > [realms] > > > BOINGO.COM = { > > > kdc = se-idm-01.boingo.com:88 (http://se-idm-01.boingo.com:88) > > > master_kdc = se-idm-01.boingo.com:88 (http://se-idm-01.boingo.com:88) > > > admin_server = se-idm-01.boingo.com:749 (http://se-idm-01.boingo.com:749) > > > default_domain = boingo.com (http://boingo.com) > > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > > } > > > > > > [domain_realm] > > > .boingo.com (http://boingo.com) = BOINGO.COM > > > boingo.com (http://boingo.com) = BOINGO.COM > > > > > > Password for admin at BOINGO.COM (mailto:admin at BOINGO.COM): > > > Starting external process > > > args=kinit admin at BOINGO.COM (mailto:admin at BOINGO.COM) > > > Process finished, return code=0 > > > stdout=Password for admin at BOINGO.COM (mailto:admin at BOINGO.COM): > > > > > > stderr= > > > trying to retrieve CA cert via LDAP from se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > flushing ldap://se-idm-01.boingo.com:389 (http://se-idm-01.boingo.com:389) from SchemaCache > > > retrieving schema for SchemaCache url=ldap://se-idm-01.boingo.com:389 (http://se-idm-01.boingo.com:389) > > > conn= > > > Existing CA cert and Retrieved CA cert are identical > > > Starting external process > > > args=/usr/sbin/ipa-join -s se-idm-01.boingo.com (http://se-idm-01.boingo.com) -b dc=boingo,dc=com -d > > > -h se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) -f > > > Process finished, return code=0 > > > stdout= > > > stderr=XML-RPC CALL: > > > > > > \r\n > > > \r\n > > > join\r\n > > > \r\n > > > \r\n > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)\r\n > > > \r\n > > > \r\n > > > nsosversion\r\n > > > 3.2.0-58-generic\r\n > > > nshardwareplatform\r\n > > > x86_64\r\n > > > \r\n > > > \r\n > > > \r\n > > > > > > XML-RPC RESPONSE: > > > > > > \n > > > \n > > > \n > > > \n > > > \n > > > fqdn=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com),cn=computers,cn=accounts,dc=boingo,dc=com\n > > > \n > > > \n > > > sshpubkeyfp\n > > > \n > > > F9:63:24:7C:AF:AF:10:F8:1E:C2:16:69:FE:EF:57:18 > > > root at 1204base (ssh-dss)\n > > > 85:E8:4E:22:E6:7E:73:0D:10:5C:CB:1A:FC:8B:DE:5C > > > root at 1204base (ssh-rsa)\n > > > B8:BF:50:00:03:BF:AD:71:34:28:CE:83:0A:74:5E:8A > > > root at 1204base (ecdsa-sha2-nistp256)\n > > > \n > > > \n > > > \n > > > has_keytab\n > > > 1\n > > > \n > > > \n > > > ipasshpubkey\n > > > \n > > > ssh-dss > > > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > > > root at 1204base\n > > > ssh-rsa > > > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > > > root at 1204base\n > > > ecdsa-sha2-nistp256 > > > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > > > root at 1204base\n > > > \n > > > \n > > > \n > > > cn\n > > > \n > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)\n > > > \n > > > \n > > > \n > > > usercertificate\n > > > \n > > > \n > > > MIIDqTCCApGgAwIBAgIBGjANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpCT0lOR08uQ09NMR4w\n > > > HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTQwMjIxMTc1MzI5WhcNMTYwMjIyMTc1\n > > > MzI5WjBCMRMwEQYDVQQKEwpCT0lOR08uQ09NMSswKQYDVQQDEyJzZS1pZG0tdWJ1bnR1LWNsaWVu\n > > > dC0wMS5ib2luZ28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2f//2Wz6UwUp\n > > > EErhWDHE+maebFuN82TQnYoAkrDGkebMOmtbLIy8fa7BdY5VNf+bJrLZkoGVq5us9aTc+s1YX63P\n > > > rmbPjFbO8+vL9I8IVIUutkUTNEhpVm0xiFe+n6jF7OXnjo/sfYZ1zT2QUyLN3TMF97hU2+QBItuJ\n > > > XY7ChOWk++YeYjgPK0xkcjbMZkNGKxKFF1qURmZVvj0VLgUxX8UwwFQZZK2XEg1Iexa+4SsKhdJN\n > > > wNagw1x99CiUXChn7V4lYZe8Uk7QDalGrgQTCVAIT+/9IpR94H6N68bHYA/hdBmV1JshTrL2Uhr0\n > > > Z2eNSjv3bpHC7BqeyWLllLw55wIDAQABo4G2MIGzMB8GA1UdIwQYMBaAFC53PmsjH7HOB4yeCQkD\n > > > z3yaIEbNMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL3NlLWlkbS0wMS5ib2lu\n > > > Z28uY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr\n > > > BgEFBQcDAjAdBgNVHQ4EFgQU7XOSHg+lb/Yizi5G81VQAT0VPQswDQYJKoZIhvcNAQELBQADggEB\n > > > AGL9mbEyxQSv9d1dbMIW1V4NOBOJFKYmEXKxuQtrOEUDTN7H7IGNm7grMgOMYzrLYs1ftRxXrySF\n > > > d8k/B3q8LBV2RQ7d0pT67cRH+YV6csmtpZ+YSOYSR+0e6F6BIsMCAU8lsjA7qvVYuaFCc+wvdiIp\n > > > rea4piqV+lxWp1m0b/mdFuCbLyXao+pr2F5JhCHueHnn14I3k+E78f07hQUccOuS0BELWo9chy+l\n > > > co7djPuzeG8MKTTr7+9L47dqhKhrY4sHyS+LhaUf3Y+irbLxgeqiBIjkV4TVkfZNZg4b6NvajgKM\n > > > L9bj5XRwrSAhv1YccwzE1GDOOrp2j3LRYIcEUok=\n > > > \n > > > \n > > > \n > > > \n > > > krbextradata\n > > > \n > > > \n > > > AAKVkgdTaG9zdC9zZS1pZG0tdWJ1bnR1LWNsaWVudC0wMS5ib2luZ28uY29tQEJPSU5HTy5DT00A\n > > > \n > > > \n > > > \n > > > \n > > > has_password\n > > > 0\n > > > \n > > > \n > > > subject\n > > > CN=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com),O=BOINGO.COM\n > > > \n > > > \n > > > ipacertificatesubjectbase\n > > > \n > > > O=BOINGO.COM\n > > > \n > > > \n > > > \n > > > sha1_fingerprint\n > > > 60:5c:7f:f5:e7:77:b7:3c:0c:c8:c0:07:3f:c3:00:18:c1:dd:9d:af\n > > > \n > > > \n > > > krblastsuccessfulauth\n > > > \n > > > 20140221181453Z\n > > > \n > > > \n > > > \n > > > serial_number\n > > > 26\n > > > \n > > > \n > > > managedby_host\n > > > \n > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)\n > > > \n > > > \n > > > \n > > > enrolledby_user\n > > > \n > > > admin\n > > > \n > > > \n > > > \n > > > dn\n > > > fqdn=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com),cn=computers,cn=accounts,dc=boingo,dc=com\n > > > \n > > > \n > > > issuer\n > > > CN=Certificate Authority,O=BOINGO.COM\n > > > \n > > > \n > > > ipauniqueid\n > > > \n > > > 459b077c-9b20-11e3-89c9-782bcb03bc6d\n > > > \n > > > \n > > > \n > > > krbprincipalname\n > > > \n > > > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM)\n > > > \n > > > \n > > > \n > > > serverhostname\n > > > \n > > > se-idm-ubuntu-client-01\n > > > \n > > > \n > > > \n > > > objectclass\n > > > \n > > > ipaobject\n > > > nshost\n > > > ipahost\n > > > pkiuser\n > > > ipaservice\n > > > krbprincipalaux\n > > > krbprincipal\n > > > ieee802device\n > > > ipasshhost\n > > > top\n > > > ipaSshGroupOfPubKeys\n > > > \n > > > \n > > > \n > > > valid_not_before\n > > > Fri Feb 21 17:53:29 2014 UTC\n > > > \n > > > \n > > > valid_not_after\n > > > Mon Feb 22 17:53:29 2016 UTC\n > > > \n > > > \n > > > fqdn\n > > > \n > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)\n > > > \n > > > \n > > > \n > > > managing_host\n > > > \n > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)\n > > > \n > > > \n > > > \n > > > md5_fingerprint\n > > > bb:dc:38:b3:19:ab:7c:07:27:31:f9:a7:78:a4:98:16\n > > > \n > > > \n > > > serial_number_hex\n > > > 0x1A\n > > > \n > > > \n > > > krblastpwdchange\n > > > \n > > > 20140221175325Z\n > > > \n > > > \n > > > \n > > > \n > > > \n > > > \n > > > \n > > > > > > Keytab successfully retrieved and stored in: /etc/krb5.keytab > > > Certificate subject base is: O=BOINGO.COM > > > > > > Enrolled in IPA realm BOINGO.COM > > > Starting external process > > > args=kdestroy > > > Process finished, return code=0 > > > stdout= > > > stderr= > > > Starting external process > > > args=/usr/bin/kinit -k -t /etc/krb5.keytab > > > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=0 > > > stdout= > > > stderr= > > > Backing up system configuration file '/etc/ipa/default.conf' > > > -> Not backing up - '/etc/ipa/default.conf' doesn't exist > > > Created /etc/ipa/default.conf > > > importing all plugin modules in > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins'... > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/aci.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automember.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/automount.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/baseldap.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/batch.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/config.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/delegation.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/dns.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/entitle.py' > > > skipping plugin module ipalib.plugins.entitle: No module named > > > rhsm.connection > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/group.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacrule.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvc.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbacsvcgroup.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hbactest.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/host.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/hostgroup.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/idrange.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/internal.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/kerberos.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/krbtpolicy.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/migration.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/misc.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/netgroup.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/passwd.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/permission.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/ping.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pkinit.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/privilege.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/pwpolicy.py' > > > Starting external process > > > args=klist -V > > > Process finished, return code=0 > > > stdout=Kerberos 5 version 1.10-beta1 > > > > > > stderr= > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/realmdomains.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/role.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selfservice.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/selinuxusermap.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/service.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmd.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudocmdgroup.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/sudorule.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/trust.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/user.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/virtual.py' > > > importing plugin module > > > '/usr/lib/python2.7/dist-packages/ipalib/plugins/xmlclient.py' > > > Backing up system configuration file '/etc/sssd/sssd.conf' > > > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > > > Domain boingo.com (http://boingo.com) is already configured in existing SSSD config, > > > creating a new one. > > > The old /etc/sssd/sssd.conf is backed up and will be restored during > > > uninstall. > > > Configured /etc/sssd/sssd.conf > > > Starting external process > > > args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i > > > /etc/ipa/ca.crt > > > Process finished, return code=0 > > > stdout= > > > stderr= > > > Backing up system configuration file '/etc/krb5.conf' > > > Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' > > > Writing Kerberos configuration to /etc/krb5.conf: > > > #File modified by ipa-client-install > > > > > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > > > > > [libdefaults] > > > default_realm = BOINGO.COM > > > dns_lookup_realm = false > > > dns_lookup_kdc = false > > > rdns = false > > > ticket_lifetime = 24h > > > forwardable = yes > > > > > > [realms] > > > BOINGO.COM = { > > > kdc = se-idm-01.boingo.com:88 (http://se-idm-01.boingo.com:88) > > > master_kdc = se-idm-01.boingo.com:88 (http://se-idm-01.boingo.com:88) > > > admin_server = se-idm-01.boingo.com:749 (http://se-idm-01.boingo.com:749) > > > default_domain = boingo.com (http://boingo.com) > > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > > } > > > > > > [domain_realm] > > > .boingo.com (http://boingo.com) = BOINGO.COM > > > boingo.com (http://boingo.com) = BOINGO.COM > > > > > > Configured /etc/krb5.conf for IPA realm BOINGO.COM > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > failed to find session_cookie in persistent storage for principal > > > 'host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM)' > > > trying https://se-idm-01.boingo.com/ipa/xml > > > Created connection context.xmlclient > > > raw: env(None, server=True) > > > env(None, server=True, all=True) > > > Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' > > > NSSConnection init se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Connecting: 66.103.90.130:0 > > > auth_certificate_callback: check_sig=True is_server=False > > > Data: > > > Version: 3 (0x2) > > > Serial Number: 10 (0xa) > > > Signature Algorithm: > > > Algorithm: PKCS #1 SHA-256 With RSA Encryption > > > Issuer: CN=Certificate Authority,O=BOINGO.COM > > > Validity: > > > Not Before: Wed Jan 22 23:22:58 2014 UTC > > > Not After : Sat Jan 23 23:22:58 2016 UTC > > > Subject: CN=se-idm-01.boingo.com (http://se-idm-01.boingo.com),O=BOINGO.COM > > > Subject Public Key Info: > > > Public Key Algorithm: > > > Algorithm: PKCS #1 RSA Encryption > > > RSA Public Key: > > > Modulus: > > > da:61:36:ca:15:d7:7f:e1:8d:6d:8b:16:f1:36:66:db: > > > 52:77:cb:54:45:24:70:ec:fb:f7:e9:3b:65:e3:39:65: > > > fe:56:90:8c:f6:6c:da:2c:7e:e4:96:6d:f8:60:57:02: > > > 93:db:91:7e:96:d1:03:03:34:ab:0a:90:39:6d:8a:e0: > > > 92:a1:1c:62:3c:61:24:51:b8:e0:87:96:5f:a0:24:85: > > > 2b:c5:43:4e:52:fd:a8:f9:28:25:00:84:53:31:51:e0: > > > 01:02:57:3d:48:26:b4:99:c4:aa:5a:51:36:f6:0f:14: > > > b2:ad:f1:15:10:05:86:ee:d1:d0:32:5b:c4:7b:4c:db: > > > 82:28:3d:62:36:43:e0:c3:7b:ed:c9:b9:c4:58:34:a1: > > > be:c5:1e:c0:b6:c7:9c:5b:1e:1d:48:b6:22:41:0e:e2: > > > 4f:43:e0:1b:e2:64:f4:57:69:67:10:64:04:7a:a4:0a: > > > 73:c5:6e:39:28:0b:76:9b:2b:b8:36:6a:59:e3:5e:84: > > > 50:ce:b6:e3:19:43:c0:f4:85:02:81:39:74:91:f5:22: > > > 04:c3:1f:49:64:39:b9:29:64:de:c4:69:76:56:a1:78: > > > 58:fd:33:28:62:77:1f:4a:3f:9d:8d:11:d2:00:0a:c0: > > > 73:1f:4f:42:89:26:a5:f2:93:a3:07:ef:3e:80:50:45 > > > Exponent: 65537 (0x10001) > > > Signed Extensions: (5) > > > Name: Certificate Authority Key Identifier > > > Critical: False > > > Key ID: > > > 2e:77:3e:6b:23:1f:b1:ce:07:8c:9e:09:09:03:cf:7c: > > > 9a:20:46:cd > > > Serial Number: None > > > General Names: [0 total] > > > > > > Name: Authority Information Access > > > Critical: False > > > > > > Name: Certificate Key Usage > > > Critical: True > > > Usages: > > > Digital Signature > > > Non-Repudiation > > > Key Encipherment > > > Data Encipherment > > > > > > Name: Extended Key Usage > > > Critical: False > > > Usages: > > > TLS Web Server Authentication Certificate > > > TLS Web Client Authentication Certificate > > > > > > Name: Certificate Subject Key ID > > > Critical: False > > > Data: > > > c5:83:cc:e3:c4:64:6f:f1:67:47:f3:cd:6a:bd:f5:2c: > > > ac:91:1e:0c > > > > > > Signature: > > > Signature Algorithm: > > > Algorithm: PKCS #1 SHA-256 With RSA Encryption > > > Signature: > > > b1:5d:69:6a:52:2a:42:4c:f7:4c:1e:f5:6e:4c:87:30: > > > f5:f5:ab:9c:ad:e5:7e:8c:e1:54:95:1d:53:56:8f:8f: > > > fc:a7:de:f2:61:f7:cd:a9:79:a7:a2:53:dd:8d:19:89: > > > ce:fb:92:bb:ca:d7:4f:84:e2:63:9b:b6:b6:a0:aa:24: > > > 10:ac:7c:ce:17:09:d1:4e:2a:8e:ae:55:fc:0a:11:52: > > > ab:23:8b:25:85:15:3c:f3:bb:0a:51:11:4f:fc:87:e1: > > > 0e:ca:12:cc:15:d4:36:57:a8:a4:db:42:0e:d1:1e:dc: > > > 1f:64:33:34:da:58:4d:a6:39:ff:b5:2c:50:6c:99:67: > > > ff:af:c0:65:d1:f6:d9:33:d5:a8:c9:9c:e3:6e:fa:b7: > > > 96:09:cd:73:eb:80:21:7d:04:af:ce:fb:76:d8:b1:ef: > > > b0:23:50:85:1c:34:9c:a2:9c:d7:c2:fd:0d:f0:bd:1f: > > > 98:ec:19:03:00:47:17:9b:a2:1d:09:3f:04:3c:59:4c: > > > 81:51:38:f0:e8:1e:74:49:5e:76:a1:d6:9a:9b:3d:fe: > > > 85:12:37:6b:3f:c7:a7:62:ce:ea:68:d8:ff:47:5a:74: > > > 41:ab:ea:0c:6a:35:e9:57:a6:3b:1f:c9:e1:12:87:8b: > > > 81:eb:c4:73:c8:a9:4d:88:a9:40:22:f9:66:06:70:b4 > > > Fingerprint (MD5): > > > 43:6b:f7:a8:12:d6:72:2f:3c:36:60:ff:ea:6b:53:a9 > > > Fingerprint (SHA1): > > > 91:b6:61:43:5d:0b:d0:14:cf:71:c8:c6:20:88:74:be: > > > ce:ad:a0:53 > > > approved_usage = SSLServer intended_usage = SSLServer > > > cert valid True for "CN=se-idm-01.boingo.com (http://se-idm-01.boingo.com),O=BOINGO.COM" > > > handshake complete, peer = 66.103.90.130:443 > > > received Set-Cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > > > Domain=se-idm-01.boingo.com (http://se-idm-01.boingo.com); Path=/ipa; Expires=Fri, 21 Feb 2014 > > > 19:47:41 GMT; Secure; HttpOnly' > > > storing cookie 'ipa_session=feebdfa3447e7a8bdae71ad28871835e; > > > Domain=se-idm-01.boingo.com (http://se-idm-01.boingo.com); Path=/ipa; Expires=Fri, 21 Feb 2014 > > > 19:47:41 GMT; Secure; HttpOnly' for principal > > > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > Starting external process > > > args=keyctl padd user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) @s > > > Process finished, return code=0 > > > stdout=546101869 > > > > > > stderr= > > > Hostname (se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)) not found in DNS > > > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > > > > > > zone boingo.com (http://boingo.com). > > > update delete se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). IN A > > > send > > > update add se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com). 1200 IN A 23.253.21.58 > > > send > > > > > > Starting external process > > > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > > > Process finished, return code=1 > > > stdout= > > > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS > > > failure. Minor code may provide more information, Minor = Server > > > DNS/ns-1454.awsdns-53.org at BOINGO.COM (mailto:ns-1454.awsdns-53.org at BOINGO.COM) not found in Kerberos database. > > > > > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' > > > returned non-zero exit status 1 > > > Failed to update DNS records. > > > Starting external process > > > args=/usr/sbin/service dbus status > > > Process finished, return code=0 > > > stdout=dbus start/running, process 1004 > > > > > > stderr= > > > Starting external process > > > args=/usr/sbin/service certmonger restart > > > Process finished, return code=0 > > > stdout=certmonger stop/waiting > > > certmonger start/running > > > > > > stderr= > > > Starting external process > > > args=/usr/sbin/service certmonger status > > > Process finished, return code=0 > > > stdout=certmonger start/running > > > > > > stderr= > > > Starting external process > > > args=/usr/sbin/service certmonger stop > > > Process finished, return code=0 > > > stdout=certmonger stop/waiting > > > > > > stderr= > > > certmonger failed to stop: [Errno 2] No such file or directory: > > > '/var/run/ipa/services.list' > > > Starting external process > > > args=/usr/sbin/service certmonger restart > > > Process finished, return code=0 > > > stdout=certmonger start/running > > > > > > stderr=stop: Unknown instance: > > > > > > Starting external process > > > args=/usr/sbin/service certmonger status > > > Process finished, return code=0 > > > stdout=certmonger start/running > > > > > > stderr= > > > Starting external process > > > args=ipa-getcert request -d /etc/pki/nssdb -n IPA Machine Certificate - > > > se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com) -N > > > CN=se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com),O=BOINGO.COM -K > > > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout=Certificate at same location is already used by request with > > > nickname "20140221175328". > > > > > > stderr= > > > certmonger request for host certificate failed > > > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > > > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > > > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > > > raw: host_mod(u'se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)', > > > ipasshpubkey=[u'ssh-rsa > > > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > > > root at 1204base', u'ssh-dss > > > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > > > root at 1204base', u'ecdsa-sha2-nistp256 > > > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > > > root at 1204base'], updatedns=False) > > > host_mod(u'se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)', random=False, > > > ipasshpubkey=(u'ssh-rsa > > > AAAAB3NzaC1yc2EAAAADAQABAAABAQCsoydbxu62xM4SHZbrPpPg95+iFLft7NnVvxPXr4rSQTUzrb+yUE1Eas5+/2wuyO3cYFPLVEe0hPF+7UHfRS7O/PiAZKvz7dSklt16lkq3BuHKi52IVwNgxsQfbD84FDCY1CaGeUScpAIVZ6JVc6D4+JM/INPsvStqreegqUy/bZRZ+YuT11AdxVTsOCwfCJWgyBPL5yDb11VfFglLm/8KnZ6asgyDeuaLNxwBySnifICX0WTx7VoQ1w8p+5Ncf7VAO8fojOZ/SwMqqP9ym7JT6OJvKL/ROd/5yZ/F21bmjZ/wKSrZDuhpZa+t6Qfn+ImrQm19VPhgdQsNZPhlE5Lv > > > root at 1204base', u'ssh-dss > > > AAAAB3NzaC1kc3MAAACBAPC0DSpZuBTz08MTehuPVq2IDPZMjSpmZz+zuQ9UbAb2yzWspsUfH3FRXMsp5M/NjKjZEUt+f5u24Q6D20Puo1qlhSW6KZv9xtx3Az/zWskvyE5XltCarOjokyjIdF4tcdlpI2onXKJBcUatZI1P9PHe+zEWMY+kbPmQ1R8h2mJTAAAAFQC1Xlgau1z17rjf5HkIBBk+d5WHJQAAAIEAut8bZLpXb1oKCQnTPV4PTXI0bAdIJWHf/4H1HN3E3rUwWwnGY/JiABBDxBJwdGnuYA9EpHZqx9+zkE86XS64Oh48VLvoVKmzMjALKnsMRDe4T5RUkxmOul36Iv+ughRNBRdO013N/j6ABj/6je73AYUGz3mKrWB+tz/szUZMAcsAAACAF73ttJiAMtcydaa63zCD+XldAk6jQwXgz0kBNTVq/n4CdFK4M+NxpH4YN93g5BQZ2IsfOlUUqrZiNy/BLrvqLBJJS+nhyLLKYEyBeiP6dnmVWw7R7A4ZX8osd4PyEAcCcfdzYGxvOJ8x5PdGu8ev8ytVEluxeHyW59vEvKlHBM0= > > > root at 1204base', u'ecdsa-sha2-nistp256 > > > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBK3ijpgDWM3+GwSGZrRIr5pXPfjJB+BXtUubwAebdVsXjgQPfD0lUjyF8jsn4Znz2PV8TFTJeCY9Nsg57aRcMmw= > > > root at 1204base'), rights=False, updatedns=False, all=False, raw=False) > > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > > > NSSConnection init se-idm-01.boingo.com (http://se-idm-01.boingo.com) > > > Connecting: 66.103.90.130:0 > > > handshake complete, peer = 66.103.90.130:443 > > > received Set-Cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > > > Domain=se-idm-01.boingo.com (http://se-idm-01.boingo.com); Path=/ipa; Expires=Fri, 21 Feb 2014 > > > 19:47:43 GMT; Secure; HttpOnly' > > > storing cookie 'ipa_session=19d25037e9a9416d6201a0fbd3faaccb; > > > Domain=se-idm-01.boingo.com (http://se-idm-01.boingo.com); Path=/ipa; Expires=Fri, 21 Feb 2014 > > > 19:47:43 GMT; Secure; HttpOnly' for principal > > > host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > Starting external process > > > args=keyctl search @s user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) > > > Process finished, return code=1 > > > stdout= > > > stderr=keyctl_search: Required key not available > > > > > > Starting external process > > > args=keyctl padd user > > > ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM (mailto:se-idm-ubuntu-client-01.boingo.com at BOINGO.COM) @s > > > Process finished, return code=0 > > > stdout=1008872903 > > > > > > stderr= > > > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no > > > modifications to be performed > > > Starting external process > > > args=/usr/sbin/service nscd status > > > Process finished, return code=1 > > > stdout= > > > stderr=nscd: unrecognized service > > > > > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > > > > > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > Does the host have the old kerberos key? > If you go to the IPA UI for the host does it still show that the host > has the key and the cert? > I bet it is. Clean both. Or remove and recreate the host entry that > might be even cleaner but you need to think about all the host > membership entries that would be deleted with this operation so use caution. > > The whole situation points to the following: > 1) Client system was once provisioned > 2) System was reimaged/reprovisioned but the unistall did not complete > or was not run or was run offline so server still thinks that the client > is still around a healthy but old instance and its keys are gone. > > To clean this situation the host entry and related certs should be clean > both on the client and server side. > > Do we have a how to about that? IMO it would be handy to have a HOWTO > that would tell "What should one do to reinstall the client if you wiped > client without doing anything on the server". > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ (http://www.redhat.com/carveoutcosts/) > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com) > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 21 23:29:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 18:29:51 -0500 Subject: [Freeipa-users] Ubuntu Client HELL In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> References: <6FB698E172A95F49BE009B36D56F53E22780C5@EXCHMB1-ELS.BWINC.local>, <5307AF96.1090903@redhat.com> <6FB698E172A95F49BE009B36D56F53E2278164@EXCHMB1-ELS.BWINC.local> Message-ID: <5307E16F.9030005@redhat.com> Todd Maugh wrote: > thanks Rob! the main issue I am having is that the install is not completing and setting this ubuntu host up as a client. > > I cleared out the old cert as you suggested, the ssh keys were copied over from a previous attempt. IM not using IPA as DNS and I understand the ntp part. > > > so now my install finishes up like this: > > Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' > NSSConnection init se-idm-01.boingo.com > Connecting: 66.103.90.130:0 > handshake complete, peer = 66.103.90.130:443 > received Set-Cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' > storing cookie 'ipa_session=8df7bbb20b25f2d7ede3c6df88f4832b; Domain=se-idm-01.boingo.com; Path=/ipa; Expires=Fri, 21 Feb 2014 20:25:02 GMT; Secure; HttpOnly' for principal host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Starting external process > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl search @s user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM > Process finished, return code=1 > stdout= > stderr=keyctl_search: Required key not available > > Starting external process > args=keyctl padd user ipa_session_cookie:host/se-idm-ubuntu-client-01.boingo.com at BOINGO.COM @s > Process finished, return code=0 > stdout=700576616 > > stderr= > Caught fault 4202 from server https://se-idm-01.boingo.com/ipa/xml: no modifications to be performed > Writing nsupdate commands to /etc/ipa/.dns_update.txt: > zone boingo.com. > update delete se-idm-ubuntu-client-01.boingo.com. IN SSHFP > send > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 1 AD5C9E4F7AEA55418455D54D84862A2B6EC16AB4 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 1 2 B1BE4E3E3B4A79CFFCE5B3BBCC31DFB9979F6A1D97EF4E3EF8F8295C2595033A > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 1 D456E5C237736406CB5F4B4C24C836217B6D977E > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 2 2 8125272934E18BFDDA77D5B03BBBF600A0833C37669C568A3476D623A191C457 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 1 270551D349212B7112D4A9079FF490C8D6733041 > update add se-idm-ubuntu-client-01.boingo.com. 1200 IN SSHFP 3 2 0BC5F5FA7155A03BD9B05DDD5882FD907A0FC8C6D6F6F3341521D4F7B57D3662 > send > > Starting external process > args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > Process finished, return code=1 > stdout= > stderr=tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/ns-1454.awsdns-53.org at BOINGO.COM not found in Kerberos database. > > nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1 > Could not update DNS SSHFP records. > Starting external process > args=/usr/sbin/service nscd status > Process finished, return code=1 > stdout= > stderr=nscd: unrecognized service > > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' > Saving StateFile to '/var/lib/ipa-client/sysrestore/sysrestore.state' It's hard to say based on this. The next thing it would do in Fedora is run authconfig. I'm unfamiliar with the Ubuntu port, particularly the upstream version it is based on. It isn't possible to know why it is failing without more information. There is no clear indication in the log of why it died. strace might be handy here. rob From sbose at redhat.com Mon Feb 24 08:31:23 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 24 Feb 2014 09:31:23 +0100 Subject: [Freeipa-users] Issues creating trust with AD. In-Reply-To: References: <20140217083433.GI15419@localhost.localdomain> <20140218093845.GU15419@localhost.localdomain> <20140219083526.GD2781@localhost.localdomain> <1392997128.22754.323.camel@willson.li.ssimo.org> Message-ID: <20140224083123.GC4363@localhost.localdomain> On Fri, Feb 21, 2014 at 11:17:38PM +0200, Genadi Postrilko wrote: > I would like to clarify myself, i wasn't accurate when i compared it to : > https://bugzilla.redhat.com/show_bug.cgi?id=878564. > ... > > *But kinit with AD users failed:* > > [root at ipaserver1 ~]# kinit Genadi at ADEXAMPLE.COM > kinit: Cannot resolve servers for KDC in realm "ADEXAMPLE.COM" while > getting initial credentials > > *But after few minutes i was able to to kinit with AD users agian:* > > [root at ipaserver1 ~]# kinit Genadi at ADEXAMPLE.COM > Password for Genadi at ADEXAMPLE.COM: The AD KDC is resolved by doing DNS SRV lookup, e.g. dig SRV _kerberos._udp.adexample.com So I would assume a DNS related issue. Did the IP address of you AD server changed after the reboot? Or did you call kinit early during the AD boot process so that the DNS server were not running? If you see this isse again, please call KRB5_TRACE=/dev/stdout kinit Genadi at ADEXAMPLE.COM This will print lots of debug information what libkrb5 is doing and might help to identify the origin of the issue. bye, Sumit > > I think i was too fast on making conclusions. > Not sure if opening a bug is needed. > > From pspacek at redhat.com Mon Feb 24 11:16:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 12:16:41 +0100 Subject: [Freeipa-users] adding ubuntu client to red hat server In-Reply-To: References: <6FB698E172A95F49BE009B36D56F53E2277B40@EXCHMB1-ELS.BWINC.local> Message-ID: <530B2A19.1080600@redhat.com> On 21.2.2014 19:51, Will Sheldon wrote: > Do you have your IPA server set as the name server for the client in /etc/resolv.conf ? Did you run command "ipa dnszone-mod example.com. --dynamic-updates=TRUE" on your IPA server? /var/log/ipaclient-install.log should contain some hints. Petr^2 Spacek > This is my install script, it may help you a bit. It does need a bit more work http://pastebin.com/mqdTZ3RU > > Ideally I?d like to convert it to an ansible playbook and have it from from the IPA host. > > Slightly unrelated, but have a read of this ticket, it makes some good suggestions at the bottom: > https://bugs.launchpad.net/bugs/1280215 > > > > Kind regards, > > Will Sheldon > +1.778-689-1244 > > > On Friday, February 21, 2014 at 9:55 AM, Todd Maugh wrote: > >> OK I got it to go through with this >> >> but i don't understand the errors cause it didn't seem to work. >> >> Domain boingo.com (http://boingo.com) is already configured in existing SSSD config, creating a new one. >> The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. >> Configured /etc/sssd/sssd.conf >> Configured /etc/krb5.conf for IPA realm BOINGO.COM >> trying https://se-idm-01.boingo.com/ipa/xml >> Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' >> Hostname (se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)) not found in DNS >> Failed to update DNS records. >> certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' >> Could not update DNS SSHFP records. >> >> >> From: Will Sheldon [mail at willsheldon.com (mailto:mail at willsheldon.com)] >> Sent: Friday, February 21, 2014 9:46 AM >> To: Todd Maugh >> Cc: freeipa-users at redhat.com (mailto:freeipa-users at redhat.com) >> Subject: Re: [Freeipa-users] adding ubuntu client to red hat server >> >> I also ran into this problem. I ended up using vm?s to test and just reverting to snapshots. >> >> I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ??force'?) >> >> >> Kind regards, >> >> Will Sheldon >> +1.778-689-1244 >> >> >> On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: >> >>> thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this >>> >>> root at se-idm-ubuntu-client-01:~# ipa-client-install --uninstall >>> Unconfigured automount client failed: [Errno 2] No such file or directory >>> certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' >>> certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' >>> Disabling client Kerberos and LDAP configurations >>> Failed to remove krb5/LDAP configuration: >>> >>> isnt there a conf file I can remove or a a way to force the uninstall? >>> >>> >>> From: Will Sheldon [mail at willsheldon.com (mailto:mail at willsheldon.com)] >>> Sent: Friday, February 21, 2014 9:32 AM >>> To: Todd Maugh >>> Cc: freeipa-users at redhat.com (mailto:freeipa-users at redhat.com) >>> Subject: Re: [Freeipa-users] adding ubuntu client to red hat server >>> >>> >>> I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. >>> >>> My script looks like: >>> >>> #revert reported version of ipapython so keys will upload properly (backup first tho) >>> cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak >>> sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py >>> >>> # install! >>> ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS >>> >>> #revert change to the ipapython version back again >>> #rm -f /usr/share/pyshared/ipapython/version.py && mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py >>> >>> >>> >>> >>> >>> Kind regards, >>> >>> Will Sheldon >>> +1.778-689-1244 >>> >>> >>> On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: >>> >>>> Hello, >>>> >>>> Another day another issue it seems :) >>>> >>>> so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. >>>> >>>> my error is as follows: >>>> >>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>> Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' >>>> host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' >>>> Failed to upload host SSH public keys. >>>> >>>> >>>> Please help From pspacek at redhat.com Mon Feb 24 14:46:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Feb 2014 15:46:40 +0100 Subject: [Freeipa-users] Announcing bind-dyndb-ldap version 4.1 Message-ID: <530B5B50.90900@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 4.1. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-4.1-1.fc20 This release *requires an LDAP server with support for RFC 4533* (aka SyncRepl) and contains other significant changes. Please read all the following text! :-) == Changes in 4.0 and 4.1 == [1] Persistent search and zone refresh were replaced by RFC 4533 (SyncRepl). Options zone_refresh, cache_ttl and psearch were removed. LDAP attributes idnsZoneRefresh and idnsPersistentSearch were removed. https://fedorahosted.org/bind-dyndb-ldap/ticket/120 [2] Internal database was re-factored and replaced by RBT DB from BIND 9. As a result, read-query performance is nearly same as with plain BIND. Wildcard records are supported and queries for non-existing records do not impose additional load on LDAP server. https://fedorahosted.org/bind-dyndb-ldap/ticket/95 https://fedorahosted.org/bind-dyndb-ldap/ticket/6 [3] Plug-in creates journal file for each DNS zone in LDAP. This allows us to support IXFR. Working directory has to be writable by named, please see README - configuration option "directory". https://fedorahosted.org/bind-dyndb-ldap/ticket/64 [4] SOA serial auto-increment feature is now mandatory. The plugin has to have write access to LDAP. (Proper SOA serial maintenance is required for journaling.) [5] Data are not served to clients until initial synchronization with LDAP is finished. All queries are answered with NXDOMAIN during synchronization. [6] Crash caused by invalid SOA record was fixed. [7] Empty instance names (specified by "dynamic-db" directive) were disallowed. [8] Typo in LDAP schema was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/121 [9] Minor bugs in error handling found by static code analyzers were fixed. Known problems and limitations [1] LDAP MODRDN (rename) is not supported at the moment. [2] Zones enabled at run-time are not loaded properly. You have to restart BIND after changing idnsZoneActive attribute to TRUE. [3] Zones and records deleted when connection to LDAP is down are not refreshed properly after re-connection. You have to restart BIND to restore consistency. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. *Make sure that BIND can write to working directory as described in README* before you restart BIND. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 3.x version is supported as long as record types not supported by old version are not utilized. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From pbrezina at redhat.com Mon Feb 24 15:46:19 2014 From: pbrezina at redhat.com (Pavel Brezina) Date: Mon, 24 Feb 2014 10:46:19 -0500 (EST) Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: Message-ID: <1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com> Hi, I wasn't able to reproduce with membership setup exactly like this. I have already seen similar problem once, unfortunately the user stopped responding before we could reach the root cause. I think it is correct from the sudo point of view, what is problematic here is missing group membership. It seems that membership of trusted user is not resolved correctly. Sumit, Jakub, do you have any ideas? On 02/19/2014 03:27 PM, Steve Dainard wrote: > Hi Pavel, > > sdainard-admin is a Windows domain user, part of an external group > 'ad_admins_external' which is a member of 'ad_admins', an ipa posix group. > > 'admins' groups is the built-in ipa admin group. > > ipa group-show admins > Group name: admins > Description: Account administrators group > GID: 1768200000 > Member users: admin > Member groups: ad_admins > Member of Sudo rule: ad_admins > Indirect Member groups: ad_admins_external > > ipa group-show ad_admins > Group name: ad_admins > Description: miovision.corp admins > GID: 1768200004 > Member users: admin > Member groups: ad_admins_external > Member of groups: admins > Member of Sudo rule: ad_admins, All > > Thanks, > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------------------------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. > If you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Wed, Feb 19, 2014 at 8:48 AM, Pavel B?ezina > wrote: > > On 02/18/2014 10:32 PM, Steve Dainard wrote: > > Hi Pavel, > > Very interesting, my IPA group membership in ad_admins isn't > shown by > that command on first run (new login) > > sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin > uid=799002462(sdainard-admin at __miovision.corp) > gid=799002462(sdainard-admin at __miovision.corp) > groups=799002462(sdainard-__admin at miovision.corp),__799001380(accounting-share-__access at miovision.corp),__799001417(protected-share-__access at miovision.corp),__799000519(enterprise > admins at miovision.corp),__799001416(hr-share-access at __miovision.corp),799000512(__domain > admins at miovision.corp),__799000513(domain > users at miovision.corp),__799002464(it - > admins at miovision.corp),__799002469(kloperators at __miovision.corp),799002468(__kladmins at miovision.corp) > > sdainard-admin at miovision.corp@__ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310. > This incident will be reported. > > But after attempting the sudo command my groups do contain the IPA > groups admins,ad_admins: > > sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin > uid=799002462(sdainard-admin at __miovision.corp) > gid=799002462(sdainard-admin at __miovision.corp) > groups=799002462(sdainard-__admin at miovision.corp),__799001380(accounting-share-__access at miovision.corp),__799001417(protected-share-__access at miovision.corp),__799000519(enterprise > admins at miovision.corp),__799001416(hr-share-access at __miovision.corp),799000512(__domain > admins at miovision.corp),__799000513(domain > users at miovision.corp),__799002464(it - > admins at miovision.corp),__799002469(kloperators at __miovision.corp),799002468(__kladmins at miovision.corp),*__1768200000(admins),1768200004(__ad_admins)* > > > sdainard-admin at miovision.corp@__ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.__corp/sdainard-admin# > > > Sudo rule (I had to create this, apparently its a default rule, but > didn't exist in my install on RHEL7 beta): > Rule name: All > Enabled: TRUE > Host category: all > Command category: all > RunAs User category: all > RunAs Group category: all > User Groups: ad_admins > > > Can you tell me more information about admins and ad_admins groups > and sdainard-admin? I would like to know how the membership is > configured and what is their relation to AD. Dump of ipa user-show > and ipa group-show should be enough, I think. > > > I saw the new dns update option (and refresh timers!), thanks. > > *Steve Dainard * > IT Infrastructure Manager > Miovision | /Rethink Traffic/ > > *Blog | **LinkedIn > __> | > Twitter > | Facebook > >* > ------------------------------__------------------------------__------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, > Kitchener, > ON, Canada | N2C 1L3 > This e-mail may contain information that is privileged or > confidential. > If you are not the intended recipient, please delete the e-mail > and any > attachments and notify us immediately. > > > On Tue, Feb 18, 2014 at 5:27 AM, Pavel B?ezina > > >> wrote: > > On 02/17/2014 10:29 PM, Steve Dainard wrote: > > I can't reproduce consistently on any OS including > Fedora 20, > but I was > able to trigger the issue on a Ubuntu 13.10 client. > > sssd: 1.11.1 > > sudo: 1.8.6p3-0ubuntu3 > > I have only just enabled the sudo logging so it should only > contain the > events below: > > sdainard-admin at miovision.corp@____ubu1310:~$ sudo su > > [sudo] password for sdainard-admin at miovision.corp: > sdainard-admin at miovision.corp is not allowed to run > sudo on ubu1310. > This incident will be reported. > sdainard-admin at miovision.corp@____ubu1310:~$ sudo su > [sudo] password for sdainard-admin at miovision.corp: > root at ubu1310:/home/miovision.____corp/sdainard-admin# > > > Files attached outside of list. > > > Hi, > thank you for the logs. Can you also send me output of > command "id > sdainard-admin" (also check if group membership is correct) and > definition of the sudo rule please? > > Also you may want to fix the following (unrelated) warning: > Deprecation warning: The option ipa_dyndns_update is > deprecated and > should not be used in favor of dyndns_update > > > > From jhrozek at redhat.com Mon Feb 24 15:55:59 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 24 Feb 2014 16:55:59 +0100 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: <1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com> References: <1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com> Message-ID: <20140224155559.GA13087@hendrix.redhat.com> On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote: > Hi, > I wasn't able to reproduce with membership setup exactly like this. I > have already seen similar problem once, unfortunately the user stopped > responding before we could reach the root cause. I think it is correct > from the sudo point of view, what is problematic here is missing group > membership. > > It seems that membership of trusted user is not resolved correctly. > Sumit, Jakub, do you have any ideas? Did you verify if "id" prints the expected groups for the user in question after he logs in? I think we need to first verify if the memberships are stored correctly to the cache.. From sbose at redhat.com Mon Feb 24 17:38:08 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 24 Feb 2014 18:38:08 +0100 Subject: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt In-Reply-To: <1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com> References: <1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com> Message-ID: <20140224173808.GE22087@localhost.localdomain> On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote: > Hi, > I wasn't able to reproduce with membership setup exactly like this. I > have already seen similar problem once, unfortunately the user stopped > responding before we could reach the root cause. I think it is correct > from the sudo point of view, what is problematic here is missing group > membership. > > It seems that membership of trusted user is not resolved correctly. > Sumit, Jakub, do you have any ideas? > > On 02/19/2014 03:27 PM, Steve Dainard wrote: ... > > > > sssd: 1.11.1 > > Do you have a chance to update at least to 1.11.3? 1.11.4 would be even better. There were couple of improvements and fixes to AD group handling in 1.11.2 and 1.11.3. bye, Sumit From zidek at kajot.cz Tue Feb 25 09:28:19 2014 From: zidek at kajot.cz (Stanislav Zidek) Date: Tue, 25 Feb 2014 10:28:19 +0100 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: References: Message-ID: <530C6233.5000100@kajot.cz> > Date: Fri, 17 Jan 2014 09:46:08 -0500 > From: Dmitri Pal > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] SSSD Failover does not work > Message-ID: <52D94230.6080108 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > You would need to up the debug_level to 6 on SSSD, restart it, then > simulate the situation and provide sanitized logs and sssd configuration > file. Hi and sorry for late reply, I've been ill and then lots of work waited for me ;) I tried to further debug the issue and I was able to make it work by adding the second ipa server also to directives ldap_uri and krb5_server (it was probably my mistake to put it only to ipa_server) - of course in /etc/sssd/sssd.conf Here is my working /etc/sssd/sssd.conf in case anyone finds it useful (or someone has a comment - feel free to tell me how to make things better): [domain/kajot.cz] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = kajot.cz id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = <<>> chpass_provider = ipa ipa_server = id1.kajot.cz, id2.kajot.cz # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://id1.kajot.cz, ldap://id2.kajot.cz ldap_sudo_search_base = ou=sudoers,dc=kajot,dc=cz ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/redmine.kajot.cz ldap_sasl_realm = KAJOT.CZ krb5_server = id1.kajot.cz, id2.kajot.cz ldap_sudo_smart_refresh_interval = 120 ldap_sudo_full_refresh_interval = 300 [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = kajot.cz [nss] [pam] [sudo] [autofs] [ssh] [pac] P.S. I hope it gets posted to the right place, Thunderbird and digest mode is probably not very good combination.. If it goes wrong, sorry in advance. S. -- Stanislav ?idek Bezpe?nostn? konzultant/analytik Security Consultant/Analyst Technick? odd?len? on-line syst?my Sekce - bezpe?nost C.S.G. Software Group Limited organiza?n? slo?ka Ka?tanov? 64, 620 00 BRNO, CZ I?:27741362 DI?:CZ27741362 Office : KAJOT Technology Center Ka?tanov? 64, 620 00 BRNO, CZ tlf: +420 515 535 134 fax: +420 515 535 134 gsm: +420 724 951 702 e-mail : zidek at kajot.cz www.kajot.com From zidek at kajot.cz Tue Feb 25 09:40:32 2014 From: zidek at kajot.cz (Stanislav Zidek) Date: Tue, 25 Feb 2014 10:40:32 +0100 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: <530C6233.5000100@kajot.cz> References: <530C6233.5000100@kajot.cz> Message-ID: <530C6510.1000408@kajot.cz> So it really get posted where I didn't mean to. I wanted to answer this: https://www.redhat.com/archives/freeipa-users/2014-January/msg00234.html Digest mode off, so no problems inf future (hopefully). S. On 02/25/2014 10:28 AM, Stanislav Zidek wrote: >> Date: Fri, 17 Jan 2014 09:46:08 -0500 >> From: Dmitri Pal >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] SSSD Failover does not work >> Message-ID: <52D94230.6080108 at redhat.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> You would need to up the debug_level to 6 on SSSD, restart it, then >> simulate the situation and provide sanitized logs and sssd configuration >> file. > > Hi and sorry for late reply, I've been ill and then lots of work waited > for me ;) > > I tried to further debug the issue and I was able to make it work by > adding the second ipa server also to directives ldap_uri and krb5_server > (it was probably my mistake to put it only to ipa_server) - of course in > /etc/sssd/sssd.conf > > Here is my working /etc/sssd/sssd.conf in case anyone finds it useful > (or someone has a comment - feel free to tell me how to make things better): > > [domain/kajot.cz] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = kajot.cz > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = <<>> > chpass_provider = ipa > ipa_server = id1.kajot.cz, id2.kajot.cz > > # For the SUDO integration > sudo_provider = ldap > ldap_uri = ldap://id1.kajot.cz, ldap://id2.kajot.cz > ldap_sudo_search_base = ou=sudoers,dc=kajot,dc=cz > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/redmine.kajot.cz > ldap_sasl_realm = KAJOT.CZ > krb5_server = id1.kajot.cz, id2.kajot.cz > > > ldap_sudo_smart_refresh_interval = 120 > ldap_sudo_full_refresh_interval = 300 > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = kajot.cz > > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > P.S. I hope it gets posted to the right place, Thunderbird and digest > mode is probably not very good combination.. If it goes wrong, sorry in > advance. > > S. > > -- > Stanislav ?idek > Bezpe?nostn? konzultant/analytik > Security Consultant/Analyst > > Technick? odd?len? on-line syst?my > Sekce - bezpe?nost > C.S.G. Software Group Limited > organiza?n? slo?ka > Ka?tanov? 64, 620 00 BRNO, CZ > I?:27741362 DI?:CZ27741362 > > Office : KAJOT Technology Center > Ka?tanov? 64, 620 00 BRNO, CZ > tlf: +420 515 535 134 fax: +420 515 535 134 > gsm: +420 724 951 702 > > e-mail : zidek at kajot.cz > www.kajot.com > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Stanislav ?idek Bezpe?nostn? konzultant/analytik Security Consultant/Analyst Technick? odd?len? on-line syst?my Sekce - bezpe?nost C.S.G. Software Group Limited organiza?n? slo?ka Ka?tanov? 64, 620 00 BRNO, CZ I?:27741362 DI?:CZ27741362 Office : KAJOT Technology Center Ka?tanov? 64, 620 00 BRNO, CZ tlf: +420 515 535 134 fax: +420 515 535 134 gsm: +420 724 951 702 e-mail : zidek at kajot.cz www.kajot.com From jhrozek at redhat.com Tue Feb 25 12:33:33 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 25 Feb 2014 13:33:33 +0100 Subject: [Freeipa-users] SSSD Failover does not work In-Reply-To: <530C6233.5000100@kajot.cz> References: <530C6233.5000100@kajot.cz> Message-ID: <20140225123333.GA4242@hendrix.brq.redhat.com> On Tue, Feb 25, 2014 at 10:28:19AM +0100, Stanislav Zidek wrote: > > Date: Fri, 17 Jan 2014 09:46:08 -0500 > > From: Dmitri Pal > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] SSSD Failover does not work > > Message-ID: <52D94230.6080108 at redhat.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > You would need to up the debug_level to 6 on SSSD, restart it, then > > simulate the situation and provide sanitized logs and sssd configuration > > file. > > Hi and sorry for late reply, I've been ill and then lots of work waited > for me ;) > > I tried to further debug the issue and I was able to make it work by > adding the second ipa server also to directives ldap_uri and krb5_server > (it was probably my mistake to put it only to ipa_server) - of course in > /etc/sssd/sssd.conf > > Here is my working /etc/sssd/sssd.conf in case anyone finds it useful > (or someone has a comment - feel free to tell me how to make things better): > > [domain/kajot.cz] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = kajot.cz > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = <<>> > chpass_provider = ipa > ipa_server = id1.kajot.cz, id2.kajot.cz > > # For the SUDO integration > sudo_provider = ldap > ldap_uri = ldap://id1.kajot.cz, ldap://id2.kajot.cz > ldap_sudo_search_base = ou=sudoers,dc=kajot,dc=cz > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/redmine.kajot.cz > ldap_sasl_realm = KAJOT.CZ > krb5_server = id1.kajot.cz, id2.kajot.cz > > > ldap_sudo_smart_refresh_interval = 120 > ldap_sudo_full_refresh_interval = 300 > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = kajot.cz > > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > P.S. I hope it gets posted to the right place, Thunderbird and digest > mode is probably not very good combination.. If it goes wrong, sorry in > advance. > > S. > Ah, I didn't realize you were mixing several provider types. It's the right thing to do for sudo intergration with RHEL-6, unfortunately. In 6.6 there will be (and there already is in 7.0 and upstream 1.9.6 and later) a native sudo_provider=ipa so you'll be able to streamline your configuration even more. From bret.wortman at damascusgrp.com Tue Feb 25 18:10:40 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 25 Feb 2014 13:10:40 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> Message-ID: <530CDCA0.4030805@damascusgrp.com> I don't know if this will be informative or not, but: # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com -------------- 1 host matched -------------- Host name: zw129.damascusgrp.com : : # I then found this pattern occurring a number of times within the (17564 line) output file: 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 4237 <... close resumed> ) = 0 4229 <... mmap resumed> ) = 0x7f936aad2000 4229 read(13, 4237 dup2(7, 0) = 0 4237 dup2(10, 1) = 1 4237 dup2(12, 2) = 2 4237 close(7) = 0 4237 close(10) = 0 4237 close(12) = 0 4237 close(3) = 0 4237 close(4) = 0 4237 close(5) = 0 4237 close(6) = 0 4237 close(7) = -1 EBADF (Bad file descriptor) 4237 close(8) = -1 EBADF (Bad file descriptor) 4237 close(9) = -1 EBADF (Bad file descriptor) 4237 close(10) = -1 EBADF (Bad file descriptor) : : Continues for a thousand entries or so, then : 4237 close(1022) = -1 EBADF (Bad file descriptor) 4237 close(1023) = -1 EBADF (Bad file descriptor) 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] Interesting, or just noise? On 02/21/2014 02:50 PM, Bret Wortman wrote: > D'oh! I'm blaming Friday. Didn't think to heck. Will try Monday. > > > Bret Wortman > http://bretwortman.com/ > http://twitter.com/BretWortman > >> On Feb 21, 2014, at 2:13 PM, Mauricio Tavares wrote: >> >> On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman >> wrote: >>> Bizarre. >>> >>> # strace -f -o /tmp/out ipa help >>> >>> Usage: ipa [global-options] COMMAND [command-options] >>> >>> : >>> >>> : >>> >>> : >>> >>> >>> # ipa help >>> >>> Connection to ipamaster closed. >>> >>> $ >> When you logged back in, did /tmp/out have anything interesting? >>> >>> >>>> On 02/21/2014 01:36 PM, Rob Crittenden wrote: >>>> >>>> Bret Wortman wrote: >>>>> I'm getting ready to leave for the weekend, and this isn't the kind of >>>>> thing I want to track down on a Friday, but if anyone has any ideas for >>>>> things I should look at come Monday morning, I'd be very appreciative. >>>>> >>>>> I've got a system with 12 replicas, and no matter which IPA server I log >>>>> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >>>>> session terminated. I also tried from a client system that has the >>>>> ipatools rpm installed, and in that case I got bounced out of my sudo'd >>>>> root session. >>>>> >>>>> I need to figure this out because something's obviously amiss, and we >>>>> have discovered a number of systems that are lacking Kerberos keys. I >>>>> was hoping the CLI would provide the mechanism to get them fixed. We're >>>>> also trying to track down a 6-10 second delay every time a user logs in >>>>> using SSSD to authenticate; the password check passes almost instantly, >>>>> but something is taking up an additional bunch of time and my users are >>>>> starting to complain. So I need to get past this so I can debug that. >>>>> >>>>> Thanks, and have a great weekend, all. >>>> >>>> For the life of me I can't figure out what the ipa command might do that >>>> would log you out. I think brute force might be a way to go with this: >>>> >>>> strace -f o /tmp/out ipa help >>>> >>>> Then go back in and see what happened. >>>> >>>> As for login delay you may want to pick a client system and bump up the >>>> sssd debug level and see if that provides any clues. >>>> >>>> rob >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From pspacek at redhat.com Tue Feb 25 19:35:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Feb 2014 20:35:09 +0100 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530CDCA0.4030805@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> Message-ID: <530CF06D.9020203@redhat.com> On 25.2.2014 19:10, Bret Wortman wrote: > I don't know if this will be informative or not, but: > > # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com > -------------- > 1 host matched > -------------- > Host name: zw129.damascusgrp.com > : > : > # > > I then found this pattern occurring a number of times within the (17564 line) > output file: > > 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0 > 4237 <... close resumed> ) = 0 > 4229 <... mmap resumed> ) = 0x7f936aad2000 > 4229 read(13, > 4237 dup2(7, 0) = 0 > 4237 dup2(10, 1) = 1 > 4237 dup2(12, 2) = 2 > 4237 close(7) = 0 > 4237 close(10) = 0 > 4237 close(12) = 0 > 4237 close(3) = 0 > 4237 close(4) = 0 > 4237 close(5) = 0 > 4237 close(6) = 0 > 4237 close(7) = -1 EBADF (Bad file descriptor) > 4237 close(8) = -1 EBADF (Bad file descriptor) > 4237 close(9) = -1 EBADF (Bad file descriptor) > 4237 close(10) = -1 EBADF (Bad file descriptor) > : > : Continues for a thousand entries or so, then > : > 4237 close(1022) = -1 EBADF (Bad file descriptor) > 4237 close(1023) = -1 EBADF (Bad file descriptor) > 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", > "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] ...> > > Interesting, or just noise? This is just a noise, unfortunately. It is common practice to close all file descriptors before you start a new program. Petr^2 Spacek > On 02/21/2014 02:50 PM, Bret Wortman wrote: >> D'oh! I'm blaming Friday. Didn't think to heck. Will try Monday. >> >> >> Bret Wortman >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >>> On Feb 21, 2014, at 2:13 PM, Mauricio Tavares wrote: >>> >>> On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman >>> wrote: >>>> Bizarre. >>>> >>>> # strace -f -o /tmp/out ipa help >>>> >>>> Usage: ipa [global-options] COMMAND [command-options] >>>> >>>> : >>>> >>>> : >>>> >>>> : >>>> >>>> >>>> # ipa help >>>> >>>> Connection to ipamaster closed. >>>> >>>> $ >>> When you logged back in, did /tmp/out have anything interesting? >>>> >>>> >>>>> On 02/21/2014 01:36 PM, Rob Crittenden wrote: >>>>> >>>>> Bret Wortman wrote: >>>>>> I'm getting ready to leave for the weekend, and this isn't the kind of >>>>>> thing I want to track down on a Friday, but if anyone has any ideas for >>>>>> things I should look at come Monday morning, I'd be very appreciative. >>>>>> >>>>>> I've got a system with 12 replicas, and no matter which IPA server I log >>>>>> into and try to run "ipa" CLI commands on (even "ipa help"), I get my >>>>>> session terminated. I also tried from a client system that has the >>>>>> ipatools rpm installed, and in that case I got bounced out of my sudo'd >>>>>> root session. >>>>>> >>>>>> I need to figure this out because something's obviously amiss, and we >>>>>> have discovered a number of systems that are lacking Kerberos keys. I >>>>>> was hoping the CLI would provide the mechanism to get them fixed. We're >>>>>> also trying to track down a 6-10 second delay every time a user logs in >>>>>> using SSSD to authenticate; the password check passes almost instantly, >>>>>> but something is taking up an additional bunch of time and my users are >>>>>> starting to complain. So I need to get past this so I can debug that. >>>>>> >>>>>> Thanks, and have a great weekend, all. >>>>> >>>>> For the life of me I can't figure out what the ipa command might do that >>>>> would log you out. I think brute force might be a way to go with this: >>>>> >>>>> strace -f o /tmp/out ipa help >>>>> >>>>> Then go back in and see what happened. >>>>> >>>>> As for login delay you may want to pick a client system and bump up the >>>>> sssd debug level and see if that provides any clues. >>>>> >>>>> rob From rcritten at redhat.com Tue Feb 25 23:06:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Feb 2014 18:06:06 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530CDCA0.4030805@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> Message-ID: <530D21DE.8010005@redhat.com> Bret Wortman wrote: > I don't know if this will be informative or not, but: > > # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com > -------------- > 1 host matched > -------------- > Host name: zw129.damascusgrp.com > : > : > # > > I then found this pattern occurring a number of times within the (17564 > line) output file: > > 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > 4237 <... close resumed> ) = 0 > 4229 <... mmap resumed> ) = 0x7f936aad2000 > 4229 read(13, > 4237 dup2(7, 0) = 0 > 4237 dup2(10, 1) = 1 > 4237 dup2(12, 2) = 2 > 4237 close(7) = 0 > 4237 close(10) = 0 > 4237 close(12) = 0 > 4237 close(3) = 0 > 4237 close(4) = 0 > 4237 close(5) = 0 > 4237 close(6) = 0 > 4237 close(7) = -1 EBADF (Bad file descriptor) > 4237 close(8) = -1 EBADF (Bad file descriptor) > 4237 close(9) = -1 EBADF (Bad file descriptor) > 4237 close(10) = -1 EBADF (Bad file descriptor) > : > : Continues for a thousand entries or so, then > : > 4237 close(1022) = -1 EBADF (Bad file descriptor) > 4237 close(1023) = -1 EBADF (Bad file descriptor) > 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", > "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] > > Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. So running with strace doesn't result in the session logging out? rob From bret.wortman at damascusgrp.com Wed Feb 26 00:31:17 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 25 Feb 2014 19:31:17 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530D21DE.8010005@redhat.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> Message-ID: <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: > > Bret Wortman wrote: >> I don't know if this will be informative or not, but: >> >> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >> -------------- >> 1 host matched >> -------------- >> Host name: zw129.damascusgrp.com >> : >> : >> # >> >> I then found this pattern occurring a number of times within the (17564 >> line) output file: >> >> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >> 4237 <... close resumed> ) = 0 >> 4229 <... mmap resumed> ) = 0x7f936aad2000 >> 4229 read(13, >> 4237 dup2(7, 0) = 0 >> 4237 dup2(10, 1) = 1 >> 4237 dup2(12, 2) = 2 >> 4237 close(7) = 0 >> 4237 close(10) = 0 >> 4237 close(12) = 0 >> 4237 close(3) = 0 >> 4237 close(4) = 0 >> 4237 close(5) = 0 >> 4237 close(6) = 0 >> 4237 close(7) = -1 EBADF (Bad file descriptor) >> 4237 close(8) = -1 EBADF (Bad file descriptor) >> 4237 close(9) = -1 EBADF (Bad file descriptor) >> 4237 close(10) = -1 EBADF (Bad file descriptor) >> : >> : Continues for a thousand entries or so, then >> : >> 4237 close(1022) = -1 EBADF (Bad file descriptor) >> 4237 close(1023) = -1 EBADF (Bad file descriptor) >> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >> > > Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. > > So running with strace doesn't result in the session logging out? > > rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From dpal at redhat.com Wed Feb 26 00:46:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 25 Feb 2014 19:46:20 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> Message-ID: <530D395C.8030500@redhat.com> On 02/25/2014 07:31 PM, Bret Wortman wrote: > Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. A theory. Your data has some output that is treated as escape sequence that crushes the shell so your connection is closed. Do you test it with the same command all the time? Have you tried other commands? Can you do a user/group/host add? Can you try other commands? > > > Bret Wortman > http://bretwortman.com/ > http://twitter.com/BretWortman > >> On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: >> >> Bret Wortman wrote: >>> I don't know if this will be informative or not, but: >>> >>> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >>> -------------- >>> 1 host matched >>> -------------- >>> Host name: zw129.damascusgrp.com >>> : >>> : >>> # >>> >>> I then found this pattern occurring a number of times within the (17564 >>> line) output file: >>> >>> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >>> 4237<... close resumed> ) = 0 >>> 4229<... mmap resumed> ) = 0x7f936aad2000 >>> 4229 read(13, >>> 4237 dup2(7, 0) = 0 >>> 4237 dup2(10, 1) = 1 >>> 4237 dup2(12, 2) = 2 >>> 4237 close(7) = 0 >>> 4237 close(10) = 0 >>> 4237 close(12) = 0 >>> 4237 close(3) = 0 >>> 4237 close(4) = 0 >>> 4237 close(5) = 0 >>> 4237 close(6) = 0 >>> 4237 close(7) = -1 EBADF (Bad file descriptor) >>> 4237 close(8) = -1 EBADF (Bad file descriptor) >>> 4237 close(9) = -1 EBADF (Bad file descriptor) >>> 4237 close(10) = -1 EBADF (Bad file descriptor) >>> : >>> : Continues for a thousand entries or so, then >>> : >>> 4237 close(1022) = -1 EBADF (Bad file descriptor) >>> 4237 close(1023) = -1 EBADF (Bad file descriptor) >>> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >>> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >>> >> Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. >> >> So running with strace doesn't result in the session logging out? >> >> rob >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 26 01:05:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Feb 2014 20:05:12 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530D395C.8030500@redhat.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> <530D395C.8030500@redhat.com> Message-ID: <530D3DC8.50407@redhat.com> Dmitri Pal wrote: > On 02/25/2014 07:31 PM, Bret Wortman wrote: >> Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. > > A theory. Your data has some output that is treated as escape sequence > that crushes the shell so your connection is closed. > Do you test it with the same command all the time? > > Have you tried other commands? > Can you do a user/group/host add? > > Can you try other commands? I think he said it fails with a simple ipa help, which eliminates a whole lot of the work we do because it does no networking in that case. Maybe running inside a typescript will show something like weird characters. rob > > >> >> >> Bret Wortman >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >>> On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: >>> >>> Bret Wortman wrote: >>>> I don't know if this will be informative or not, but: >>>> >>>> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >>>> -------------- >>>> 1 host matched >>>> -------------- >>>> Host name: zw129.damascusgrp.com >>>> : >>>> : >>>> # >>>> >>>> I then found this pattern occurring a number of times within the (17564 >>>> line) output file: >>>> >>>> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >>>> 4237 <... close resumed> ) = 0 >>>> 4229 <... mmap resumed> ) = 0x7f936aad2000 >>>> 4229 read(13, >>>> 4237 dup2(7, 0) = 0 >>>> 4237 dup2(10, 1) = 1 >>>> 4237 dup2(12, 2) = 2 >>>> 4237 close(7) = 0 >>>> 4237 close(10) = 0 >>>> 4237 close(12) = 0 >>>> 4237 close(3) = 0 >>>> 4237 close(4) = 0 >>>> 4237 close(5) = 0 >>>> 4237 close(6) = 0 >>>> 4237 close(7) = -1 EBADF (Bad file descriptor) >>>> 4237 close(8) = -1 EBADF (Bad file descriptor) >>>> 4237 close(9) = -1 EBADF (Bad file descriptor) >>>> 4237 close(10) = -1 EBADF (Bad file descriptor) >>>> : >>>> : Continues for a thousand entries or so, then >>>> : >>>> 4237 close(1022) = -1 EBADF (Bad file descriptor) >>>> 4237 close(1023) = -1 EBADF (Bad file descriptor) >>>> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >>>> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >>>> >>> Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. >>> >>> So running with strace doesn't result in the session logging out? >>> >>> rob >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From bret.wortman at damascusgrp.com Wed Feb 26 01:32:15 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 25 Feb 2014 20:32:15 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530D3DC8.50407@redhat.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> <530D395C.8030500@redhat.com> <530D3DC8.50407@redhat.com> Message-ID: I'll try that. And you're right--we've tried a number of sub commands. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman > On Feb 25, 2014, at 8:05 PM, Rob Crittenden wrote: > > Dmitri Pal wrote: >>> On 02/25/2014 07:31 PM, Bret Wortman wrote: >>> Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. >> >> A theory. Your data has some output that is treated as escape sequence >> that crushes the shell so your connection is closed. >> Do you test it with the same command all the time? >> >> Have you tried other commands? >> Can you do a user/group/host add? >> >> Can you try other commands? > > I think he said it fails with a simple ipa help, which eliminates a whole lot of the work we do because it does no networking in that case. > > Maybe running inside a typescript will show something like weird characters. > > rob > >> >> >>> >>> >>> Bret Wortman >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>>> On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: >>>> >>>> Bret Wortman wrote: >>>>> I don't know if this will be informative or not, but: >>>>> >>>>> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >>>>> -------------- >>>>> 1 host matched >>>>> -------------- >>>>> Host name: zw129.damascusgrp.com >>>>> : >>>>> : >>>>> # >>>>> >>>>> I then found this pattern occurring a number of times within the (17564 >>>>> line) output file: >>>>> >>>>> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >>>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >>>>> 4237 <... close resumed> ) = 0 >>>>> 4229 <... mmap resumed> ) = 0x7f936aad2000 >>>>> 4229 read(13, >>>>> 4237 dup2(7, 0) = 0 >>>>> 4237 dup2(10, 1) = 1 >>>>> 4237 dup2(12, 2) = 2 >>>>> 4237 close(7) = 0 >>>>> 4237 close(10) = 0 >>>>> 4237 close(12) = 0 >>>>> 4237 close(3) = 0 >>>>> 4237 close(4) = 0 >>>>> 4237 close(5) = 0 >>>>> 4237 close(6) = 0 >>>>> 4237 close(7) = -1 EBADF (Bad file descriptor) >>>>> 4237 close(8) = -1 EBADF (Bad file descriptor) >>>>> 4237 close(9) = -1 EBADF (Bad file descriptor) >>>>> 4237 close(10) = -1 EBADF (Bad file descriptor) >>>>> : >>>>> : Continues for a thousand entries or so, then >>>>> : >>>>> 4237 close(1022) = -1 EBADF (Bad file descriptor) >>>>> 4237 close(1023) = -1 EBADF (Bad file descriptor) >>>>> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >>>>> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >>>>> >>>> Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. >>>> >>>> So running with strace doesn't result in the session logging out? >>>> >>>> rob >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From raubvogel at gmail.com Wed Feb 26 05:22:00 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Wed, 26 Feb 2014 00:22:00 -0500 Subject: [Freeipa-users] On ipadiscovery.py Message-ID: Trying to understand the class IPADiscovery and why it does not like my ubuntu64 box and my network: 1. We start with root at ubuntu64:~# ipa-client-install DNS discovery failed to determine your DNS domain Provide the domain name of your IPA server (ex: example.com): I take most of the hot action is happening in ipadiscovery.py. Am I correct to assume that check_domain is looking for lines that contain "domain" in them? Mine looks like this: root at ubuntu64:~# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.0.0.1 search in.domain.com root at ubuntu64:~# which would (I hope) explain the following entries in the log file: 2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)] 2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)] 2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(com)] 2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)] 2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)] 2014-02-25 23:41:05,996 DEBUG [ipadnssearchldap(com)] 2014-02-25 23:41:05,996 DEBUG Domain not found 2. In ipadnssearchldap, are the lines qname = "_ldap._tcp."+tdomain # terminate the name if not qname.endswith("."): qname += "." results = ipapython.dnsclient.query(qname, ipapython.dnsclient.DNS_C_IN, ipapython.dnsclient.DNS_T_SRV) supposed to do something like root at ubuntu64:~# dig +short _ldap._tcp.in.domain.com SRV 0 0 389 auth.in.domain.com. root at ubuntu64:~# From abokovoy at redhat.com Wed Feb 26 05:44:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Feb 2014 07:44:48 +0200 Subject: [Freeipa-users] On ipadiscovery.py In-Reply-To: References: Message-ID: <20140226054448.GA16644@redhat.com> On Wed, 26 Feb 2014, Mauricio Tavares wrote: > Trying to understand the class IPADiscovery and why it does not >like my ubuntu64 box and my network: > >1. We start with > >root at ubuntu64:~# ipa-client-install >DNS discovery failed to determine your DNS domain >Provide the domain name of your IPA server (ex: example.com): > >I take most of the hot action is happening in ipadiscovery.py. Am I >correct to assume that check_domain is looking for lines that contain >"domain" in them? Mine looks like this: > >root at ubuntu64:~# cat /etc/resolv.conf ># Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) ># DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN >nameserver 10.0.0.1 >search in.domain.com >root at ubuntu64:~# > >which would (I hope) explain the following entries in the log file: > >2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)] >2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)] >2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(com)] >2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)] >2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)] >2014-02-25 23:41:05,996 DEBUG [ipadnssearchldap(com)] >2014-02-25 23:41:05,996 DEBUG Domain not found Run ipa-client-install under strace -f -s 4096 -tt and see the log what exactly it contacts through the resolver. -- / Alexander Bokovoy From bret.wortman at damascusgrp.com Wed Feb 26 12:25:54 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 26 Feb 2014 07:25:54 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> <530D395C.8030500@redhat.com> <530D3DC8.50407@redhat.com> Message-ID: <530DDD52.8000102@damascusgrp.com> # script /tmp/out-script Script started, file is /tmp/out-script # ipa help Script done, file is /tmp/out-script # cat /tmp/out-script Script started on Wed 26 Feb 2014 07:18:07 AM EST # ipa help Script done on Wed 26 Feb 2014 07:18:14 AM EST # So then I tried it using script's "-c" option to see if that would make a difference, kind of like strace did: #script -c 'ipa help' /tmp/out-script2 Script started, file is /tmp/out-script2 Usage: ipa [global-options] COMMAND {command-options] Manage an IPA domain Options: : : See "ipa --help" for more information on a specific command. Script done, file is /tmp/out-script2 # cat /tmp/out-script2 Script started on Wed 26 Feb 2014 07:20:27 AM EST Usage: ipa [global-options] COMMAND [command-options] Manage an IPA domain Options: : : See "ipa --help" for more information on a specific command. Script done on Wed 26 Feb 2014 07:20:28 AM EST # It /looks/ like something is behaving differently when input comes from a tty vice when it doesn't. For grins, I did the same thing using "ipa host-find zw129.damascusgrp.com" and got basically the same result -- an empty log first, then successful completion (including expected results) using the -c option. Bret On 02/25/2014 08:32 PM, Bret Wortman wrote: > I'll try that. And you're right--we've tried a number of sub commands. > > > Bret Wortman > http://bretwortman.com/ > http://twitter.com/BretWortman > >> On Feb 25, 2014, at 8:05 PM, Rob Crittenden wrote: >> >> Dmitri Pal wrote: >>>> On 02/25/2014 07:31 PM, Bret Wortman wrote: >>>> Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. >>> A theory. Your data has some output that is treated as escape sequence >>> that crushes the shell so your connection is closed. >>> Do you test it with the same command all the time? >>> >>> Have you tried other commands? >>> Can you do a user/group/host add? >>> >>> Can you try other commands? >> I think he said it fails with a simple ipa help, which eliminates a whole lot of the work we do because it does no networking in that case. >> >> Maybe running inside a typescript will show something like weird characters. >> >> rob >> >>> >>>> >>>> Bret Wortman >>>> http://bretwortman.com/ >>>> http://twitter.com/BretWortman >>>> >>>>> On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: >>>>> >>>>> Bret Wortman wrote: >>>>>> I don't know if this will be informative or not, but: >>>>>> >>>>>> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >>>>>> -------------- >>>>>> 1 host matched >>>>>> -------------- >>>>>> Host name: zw129.damascusgrp.com >>>>>> : >>>>>> : >>>>>> # >>>>>> >>>>>> I then found this pattern occurring a number of times within the (17564 >>>>>> line) output file: >>>>>> >>>>>> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >>>>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >>>>>> 4237 <... close resumed> ) = 0 >>>>>> 4229 <... mmap resumed> ) = 0x7f936aad2000 >>>>>> 4229 read(13, >>>>>> 4237 dup2(7, 0) = 0 >>>>>> 4237 dup2(10, 1) = 1 >>>>>> 4237 dup2(12, 2) = 2 >>>>>> 4237 close(7) = 0 >>>>>> 4237 close(10) = 0 >>>>>> 4237 close(12) = 0 >>>>>> 4237 close(3) = 0 >>>>>> 4237 close(4) = 0 >>>>>> 4237 close(5) = 0 >>>>>> 4237 close(6) = 0 >>>>>> 4237 close(7) = -1 EBADF (Bad file descriptor) >>>>>> 4237 close(8) = -1 EBADF (Bad file descriptor) >>>>>> 4237 close(9) = -1 EBADF (Bad file descriptor) >>>>>> 4237 close(10) = -1 EBADF (Bad file descriptor) >>>>>> : >>>>>> : Continues for a thousand entries or so, then >>>>>> : >>>>>> 4237 close(1022) = -1 EBADF (Bad file descriptor) >>>>>> 4237 close(1023) = -1 EBADF (Bad file descriptor) >>>>>> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >>>>>> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >>>>>> >>>>> Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. >>>>> >>>>> So running with strace doesn't result in the session logging out? >>>>> >>>>> rob >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From sdainard at miovision.com Wed Feb 26 21:24:54 2014 From: sdainard at miovision.com (Steve Dainard) Date: Wed, 26 Feb 2014 16:24:54 -0500 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <5298A78C.1090400@redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> Message-ID: Would it not be possible for root to disable selinux enforcement? A user could maybe even use a livecd if root couldn't be gained directly. I'm looking at joining workstations to an idm realm, but some users will need sudo permissions on their machines. Is there any documentation on best practices here? Has there been any further discussion on the best way to approach this problem? Thanks, *Steve Dainard * IT Infrastructure Manager Miovision | *Rethink Traffic* *Blog | **LinkedIn | Twitter | Facebook * ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek wrote: > On 11/29/2013 03:17 PM, Jakub Hrozek wrote: > > On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: > >> Jakub, > >> > >> Yes, I could do this. But then the local root account cannot su to local > >> users (without password). But that is actually a normal use-case. I just > >> think local root should not be allowed to transition to a domain user, > by > >> default. > >> > >> Fred > > > > Ah, in that case I'm not sure if there's an easy solution, at least I > > don't know any off hand. I think Alexander is right that SELinux would > > be a good choice. > > Right. Root could uncomment the pam_rootok.so line anyway if he wanted to > access other user's account again. > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 26 21:33:33 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 26 Feb 2014 16:33:33 -0500 Subject: [Freeipa-users] Trying to use the CLI logs me out In-Reply-To: <530DDD52.8000102@damascusgrp.com> References: <530797D8.5040101@damascusgrp.com> <53079C92.4080809@redhat.com> <5307A37C.30109@damascusgrp.com> <911FBF07-2E6C-4E79-8D06-E739FBF60425@damascusgrp.com> <530CDCA0.4030805@damascusgrp.com> <530D21DE.8010005@redhat.com> <25C0D8DE-9D00-4257-A207-8FAB106B9867@damascusgrp.com> <530D395C.8030500@redhat.com> <530D3DC8.50407@redhat.com> <530DDD52.8000102@damascusgrp.com> Message-ID: <530E5DAD.6030008@redhat.com> On 02/26/2014 07:25 AM, Bret Wortman wrote: > # script /tmp/out-script > Script started, file is /tmp/out-script > # ipa help > Script done, file is /tmp/out-script > # cat /tmp/out-script > > Script started on Wed 26 Feb 2014 07:18:07 AM EST > # ipa help > > Script done on Wed 26 Feb 2014 07:18:14 AM EST > # > > So then I tried it using script's "-c" option to see if that would > make a difference, kind of like strace did: > > #script -c 'ipa help' /tmp/out-script2 > Script started, file is /tmp/out-script2 > Usage: ipa [global-options] COMMAND {command-options] > > Manage an IPA domain > > Options: > : > : > See "ipa --help" for more information on a specific command. > Script done, file is /tmp/out-script2 > # cat /tmp/out-script2 > Script started on Wed 26 Feb 2014 07:20:27 AM EST > Usage: ipa [global-options] COMMAND [command-options] > > Manage an IPA domain > > Options: > : > : These colons... Where do they come from. Can it be that something here is interpreted in strange way? Can be some kind of weird new line conversion in the output that cause the shell to go south? Any strange settings in ENV defining terminal settings? Can you do any python based output? > See "ipa --help" for more information on a specific command. > > Script done on Wed 26 Feb 2014 07:20:28 AM EST > # > > It /looks/ like something is behaving differently when input comes > from a tty vice when it doesn't. For grins, I did the same thing using > "ipa host-find zw129.damascusgrp.com" and got basically the same > result -- an empty log first, then successful completion (including > expected results) using the -c option. > > > Bret > > On 02/25/2014 08:32 PM, Bret Wortman wrote: >> I'll try that. And you're right--we've tried a number of sub commands. >> >> >> Bret Wortman >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >>> On Feb 25, 2014, at 8:05 PM, Rob Crittenden wrote: >>> >>> Dmitri Pal wrote: >>>>> On 02/25/2014 07:31 PM, Bret Wortman wrote: >>>>> Nope, running with strace lets us use the IPA command again with impunity. Without it, process termination. >>>> A theory. Your data has some output that is treated as escape sequence >>>> that crushes the shell so your connection is closed. >>>> Do you test it with the same command all the time? >>>> >>>> Have you tried other commands? >>>> Can you do a user/group/host add? >>>> >>>> Can you try other commands? >>> I think he said it fails with a simple ipa help, which eliminates a whole lot of the work we do because it does no networking in that case. >>> >>> Maybe running inside a typescript will show something like weird characters. >>> >>> rob >>> >>>>> Bret Wortman >>>>> http://bretwortman.com/ >>>>> http://twitter.com/BretWortman >>>>> >>>>>> On Feb 25, 2014, at 6:06 PM, Rob Crittenden wrote: >>>>>> >>>>>> Bret Wortman wrote: >>>>>>> I don't know if this will be informative or not, but: >>>>>>> >>>>>>> # strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com >>>>>>> -------------- >>>>>>> 1 host matched >>>>>>> -------------- >>>>>>> Host name: zw129.damascusgrp.com >>>>>>> : >>>>>>> : >>>>>>> # >>>>>>> >>>>>>> I then found this pattern occurring a number of times within the (17564 >>>>>>> line) output file: >>>>>>> >>>>>>> 4229 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, >>>>>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 >>>>>>> 4237<... close resumed> ) = 0 >>>>>>> 4229<... mmap resumed> ) = 0x7f936aad2000 >>>>>>> 4229 read(13, >>>>>>> 4237 dup2(7, 0) = 0 >>>>>>> 4237 dup2(10, 1) = 1 >>>>>>> 4237 dup2(12, 2) = 2 >>>>>>> 4237 close(7) = 0 >>>>>>> 4237 close(10) = 0 >>>>>>> 4237 close(12) = 0 >>>>>>> 4237 close(3) = 0 >>>>>>> 4237 close(4) = 0 >>>>>>> 4237 close(5) = 0 >>>>>>> 4237 close(6) = 0 >>>>>>> 4237 close(7) = -1 EBADF (Bad file descriptor) >>>>>>> 4237 close(8) = -1 EBADF (Bad file descriptor) >>>>>>> 4237 close(9) = -1 EBADF (Bad file descriptor) >>>>>>> 4237 close(10) = -1 EBADF (Bad file descriptor) >>>>>>> : >>>>>>> : Continues for a thousand entries or so, then >>>>>>> : >>>>>>> 4237 close(1022) = -1 EBADF (Bad file descriptor) >>>>>>> 4237 close(1023) = -1 EBADF (Bad file descriptor) >>>>>>> 4237 execve("/bin/keyctl", ["keyctl", "padd", "user", >>>>>>> "ipa_session_cookie:admin at DAMASCUSGRP.COM", "@s"], [/* 27 vars */] >>>>>>> >>>>>> Just noise while we fork off and run another process, in this case keyctl to store the session cookie in the kernel keyring. >>>>>> >>>>>> So running with strace doesn't result in the session logging out? >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs? >>>> www.redhat.com/carveoutcosts/ >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From harvero at gmail.com Thu Feb 27 14:48:43 2014 From: harvero at gmail.com (Bob) Date: Thu, 27 Feb 2014 09:48:43 -0500 Subject: [Freeipa-users] AD password synchronization Message-ID: How can I create the id=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com account without creating a replication agreement. I do not want to replicate accounts between AD and ipa, but I do want password changes on AD to be sent to ipa. Is this possible? thanks, Bob H -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 27 15:49:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Feb 2014 10:49:27 -0500 Subject: [Freeipa-users] AD password synchronization In-Reply-To: References: Message-ID: <530F5E87.8010407@redhat.com> Bob wrote: > > How can I create the id=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com account without creating a replication agreement. > > I do not want to replicate accounts between AD and ipa, but I do want password changes on AD to be sent to ipa. > > > Is this possible? # ldapmodify -D "cn=directory manager" -w secret -p 389 -h ipaserver.example.com -x -a dn: uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com objectClass: account objectClass: simplesecurityobject objectClass: top uid: passsync userPassword: secretpassword As for how well this will work, I'm not sure. You'll also need to add this to the pass sync managers entry ala https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/pass-sync.html I forget the details on how the PassSync service links the AD entry to the 389-ds entry. You may need to add additional attributes to IPA for each user you want to keep synchronized. rob From jhrozek at redhat.com Thu Feb 27 20:06:44 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 27 Feb 2014 21:06:44 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> Message-ID: <20140227200644.GP27086@hendrix.brq.redhat.com> On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: > Would it not be possible for root to disable selinux enforcement? Normally yes, if you're root, you can do all kinds of stuff including appending 'selinux=0' to the kernel command line. Maybe there are better SELinux experts on the list, but if you need to partition the power of root further, maybe MLS SELinux configuration is what you need? > A user > could maybe even use a livecd if root couldn't be gained directly. Can you protect the bootloader with a password? btw if malicious users have physical access to the hardware, then you're in a difficult situation anyway.. > > I'm looking at joining workstations to an idm realm, but some users will > need sudo permissions on their machines. Do they need the full sudo permissions (to become root) ? Can you just give them permissions to run specific commands (ie /sbin/service etc) ? > > Is there any documentation on best practices here? Has there been any > further discussion on the best way to approach this problem? > > Thanks, > > *Steve Dainard * > IT Infrastructure Manager > Miovision | *Rethink Traffic* > > *Blog | **LinkedIn > | Twitter > | Facebook > * > ------------------------------ > Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, > Canada | N2C 1L3 > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > > > On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek wrote: > > > On 11/29/2013 03:17 PM, Jakub Hrozek wrote: > > > On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: > > >> Jakub, > > >> > > >> Yes, I could do this. But then the local root account cannot su to local > > >> users (without password). But that is actually a normal use-case. I just > > >> think local root should not be allowed to transition to a domain user, > > by > > >> default. > > >> > > >> Fred > > > > > > Ah, in that case I'm not sure if there's an easy solution, at least I > > > don't know any off hand. I think Alexander is right that SELinux would > > > be a good choice. > > > > Right. Root could uncomment the pam_rootok.so line anyway if he wanted to > > access other user's account again. > > > > Martin > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > From bnordgren at fs.fed.us Thu Feb 27 21:03:35 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 27 Feb 2014 21:03:35 +0000 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20140227200644.GP27086@hendrix.brq.redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> > On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: > > Would it not be possible for root to disable selinux enforcement? It should also be possible to copy private keys out of ~user/.ssh and login to other machines as "user", assuming no password on the ssh key pair. It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to "take back the night" is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your "organizational system". [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? Bryce [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From dpal at redhat.com Thu Feb 27 21:28:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 27 Feb 2014 16:28:05 -0500 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <530FADE5.30806@redhat.com> On 02/27/2014 04:03 PM, Nordgren, Bryce L -FS wrote: >> On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: >>> Would it not be possible for root to disable selinux enforcement? > It should also be possible to copy private keys out of ~user/.ssh and login to other machines as "user", assuming no password on the ssh key pair. > > It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to "take back the night" is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. > > One thing that is nagging at me: I read that sssd caches your credentials in a form such that they can be retrieved and provided to your "organizational system". [1] This seems like a vector for a knowledgeable, malicious admin to break out of the client machine and impersonate someone else to any domain service. Is there a safeguard against this? SSSD will do catching and storing password only if configured and if the system can't connect to the central server so potentially a bad root admin can configure SSSD to store passwords and then lure other users to connect to the box and while the box is not connected to the central server passwords will be local and root would be able to steal them and impersonate uses. But I would argue that in this case root can just add some other module to the pam stack that would dump passwords for any user who uses pam stack regardless whether SSSD is in the picture or not so it is not SSSD problem and I do not think it can be generally solved with the software. It is the point where you cross the line into physical security and organization's security and trust policies. > > Bryce > > [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html > > > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From michal.zacek at img.cas.cz Thu Feb 27 22:01:59 2014 From: michal.zacek at img.cas.cz (Michal Zacek) Date: Thu, 27 Feb 2014 23:01:59 +0100 Subject: [Freeipa-users] winsync and new users Message-ID: <530FB5D7.9040002@img.cas.cz> Hi, I have successfully completed agreement between Windows and IPA and it works. When I create user in Windows, it's synchronized to IPA and when I change something on IPA for this user, it's synchronized back to Windows, but when I create *new* user in IPA it's not synchronized (created) in Windows. Is this the way how it's supposed to work? New user are synchronized only from Windows to IPA? Thanks for your reply. Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 27 22:08:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 27 Feb 2014 17:08:52 -0500 Subject: [Freeipa-users] winsync and new users In-Reply-To: <530FB5D7.9040002@img.cas.cz> References: <530FB5D7.9040002@img.cas.cz> Message-ID: <530FB774.2070109@redhat.com> On 02/27/2014 05:01 PM, Michal Zacek wrote: > Hi, > > I have successfully completed agreement between Windows and IPA and it > works. When I create user in Windows, it's synchronized to IPA and > when I change something on IPA for this user, it's synchronized back > to Windows, but when I create *new* user in IPA it's not synchronized > (created) in Windows. Is this the way how it's supposed to work? New > user are synchronized only from Windows to IPA? > > Thanks for your reply. Yes. It is a one way sync. > > Michal > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 27 22:11:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Feb 2014 00:11:00 +0200 Subject: [Freeipa-users] winsync and new users In-Reply-To: <530FB5D7.9040002@img.cas.cz> References: <530FB5D7.9040002@img.cas.cz> Message-ID: <20140227221100.GX16644@redhat.com> On Thu, 27 Feb 2014, Michal Zacek wrote: >Hi, > >I have successfully completed agreement between Windows and IPA and >it works. When I create user in Windows, it's synchronized to IPA >and when I change something on IPA for this user, it's synchronized >back to Windows, but when I create *new* user in IPA it's not >synchronized (created) in Windows. Is this the way how it's supposed >to work? New user are synchronized only from Windows to IPA? Yes, that's how it is supposed to work. -- / Alexander Bokovoy From bnordgren at fs.fed.us Thu Feb 27 22:36:01 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 27 Feb 2014 22:36:01 +0000 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <530FADE5.30806@redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <530FADE5.30806@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6910D6@001FSN2MPN1-045.001f.mgd2.msft.net> > But I > would argue that in this case root can just add some other module to the > pam stack that would dump passwords for any user who uses pam stack > regardless whether SSSD is in the picture or not so it is not SSSD problem and > I do not think it can be generally solved with the software. It is the point > where you cross the line into physical security and organization's security and > trust policies. In a Kerberos/IdM/AD environment, the password isn't available except at initial sign on. If I sign on using my machine, then ssh to user Evil's machine, the worst user Evil can do is steal my TGT, which has a much shorter life than a password. If Evil is quick, he can get at my files on the main server. But I never give my password to user Evil in this situation, and user Evil is not an admin on my box, where he can affect the pam stack. Thinking this through...This is definitely not a physical security thing: the machine was issued to user Evil and Evil must have physical access to it. These factors are not amenable to change. The problem is that "risk" and "granting power" are two sides of the same coin. The challenge is to grant useful amounts of power while mitigating risk to others. For instance: the above description suggests that one way to mitigate risk is to not delegate administrative control over machines which handle other people's passwords. Whether this is "policy" or just "good practice" is perhaps a matter of semantics. Either way: Training the users to do the initial signon on their own box will go a long way to eliminating the need for a technical control...Definitely not a software problem... This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From jhrozek at redhat.com Thu Feb 27 22:49:31 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 27 Feb 2014 23:49:31 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <20140227224931.GV27086@hendrix.brq.redhat.com> On Thu, Feb 27, 2014 at 09:03:35PM +0000, Nordgren, Bryce L -FS wrote: > > > On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote: > > > Would it not be possible for root to disable selinux enforcement? > > It should also be possible to copy private keys out of ~user/.ssh and login to other machines as "user", assuming no password on the ssh key pair. > > It's probably best to assume that all your client machines are under the control of knowledgeable, malicious admins, and to put your important information somewhere other than your client machines. The only real way to "take back the night" is to force your users to connect to a service you control using an authentication mechanism you control. (e.g., Kerberos service tickets: accept no substitute. :) ) Prohibiting them from making any changes makes you responsible for every last customization. Delegating frees you up, but requires trust. Probably a good rule of thumb is to be generous doling out permissions when only one person will ever use the machine. Giving someone control over someone else's workspace should require consent of the controlled. > > One thing that is nagging at me: I read that sssd caches your > credentials in a form such that they can be retrieved and provided to your > "organizational system". [1] This seems like a vector for a knowledgeable, > malicious admin to break out of the client machine and impersonate someone > else to any domain service. Is there a safeguard against this? Caching credentials is disabled by default[1]. Even when credential caching is enabled, the cache is only ever readable by root, the hashes are *never* exposed to the system. FYI, the hash is a salted sha512. What leads you to believe the cached credentials can be retrieved? [1] in sssd upstream. ipa-client-install enables caching credentials. From jhrozek at redhat.com Thu Feb 27 23:06:25 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 28 Feb 2014 00:06:25 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6910D6@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <530FADE5.30806@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6910D6@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <20140227230625.GW27086@hendrix.brq.redhat.com> On Thu, Feb 27, 2014 at 10:36:01PM +0000, Nordgren, Bryce L -FS wrote: > > > > But I > > would argue that in this case root can just add some other module to the > > pam stack that would dump passwords for any user who uses pam stack > > regardless whether SSSD is in the picture or not so it is not SSSD problem and > > I do not think it can be generally solved with the software. It is the point > > where you cross the line into physical security and organization's security and > > trust policies. > > In a Kerberos/IdM/AD environment, the password isn't available except at > initial sign on. If I sign on using my machine, then ssh to user Evil's > machine, the worst user Evil can do is steal my TGT, which has a much > shorter life than a password. If Evil is quick, he can get at my files on > the main server. But I never give my password to user Evil in this situation, > and user Evil is not an admin on my box, where he can affect the pam stack. > Assuming you're using the TGT (acquired on your machine) to SSH to Evil, it's still the same case and the SSSD is not even involved. If you're typing your Kerberos password to a machine controlled by Evil, you have problems :-) But that's true with or without SSSD. From rmeggins at redhat.com Thu Feb 27 23:29:56 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Feb 2014 16:29:56 -0700 Subject: [Freeipa-users] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past In-Reply-To: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> References: <16593317-8E16-4B98-AF7D-F32E6BBB9BA9@citrixonline.com> Message-ID: <530FCA74.9040606@redhat.com> On 02/03/2014 10:37 PM, JR Aquino wrote: > If you are seeing clock skew errors in > /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you > will need to verify the time/date of the server to make sure NTP isn't > freaked out. If the system date is correct, it is possible that the > change number generator has skewed. Thanks much JR! I have wiki-fied this email http://port389.org/wiki/Howto:Fix_and_Reset_Time_Skew I would like to credit you on the page - how would you like to be attributed? > > [01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 > repl="dc=example,dc=com": Excessive clock skew from supplier RUV > [01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit > exceeded; value - 1448518, limit - 86400 > [01/Feb/2014:14:42:06 -0800] - CSN generator's state: > [01/Feb/2014:14:42:06 -0800] - replica id: 115 > [01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526 > [01/Feb/2014:14:42:06 -0800] - local offset: 0 > [01/Feb/2014:14:42:06 -0800] - remote offset: 0 > [01/Feb/2014:14:42:06 -0800] - sequence number: 55067 > > The following NsState_Script should be used to determine whether the > change number generator has jumped significantly from the real time/date. > https://github.com/richm/scripts/blob/master/readNsState.py > > > The usage for the script works like this: > > [root at ipaserver.ops jaquino]# ./readNsState.py > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > nsState is cwAAAAAAAABGPfBSAAAAAAAAAAAAAAAAAQAAAAAAAAACAAAAAAAAAA== > Little Endian > For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config > fmtstr=[H6x3QH6x] > size=40 > len of nsstate is 40 > CSN generator state: > Replica ID : 115 > Sampled Time : 1391476038 > Gen as csn : 52f03d46000201150000 > Time as str : Mon Feb 3 17:07:18 2014 > Local Offset : 0 > Remote Offset : 1 > Seq. num : 2 > System time : Mon Feb 3 17:09:11 2014 > Diff in sec. : 113 > Day:sec diff : 0:113 > > If the output from the above command is over a day or more out of > sync, then the reason is because the CSN generator has become grossly > skewed. It will be necessary to perform the following steps to recover. > > -------------------------------------------- > How to resolve this issue > > ? 1: Select an ipa server to be authoritative and write the contents > of its database to an ldif file > On the master supplier: > /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory > Manager' -w - -n userRoot -a /tmp/master-389.ldif > Note that without the -r option it is deliberately ommiting the > tainted replication data which contains the bad CSNs > > ? 2: On the ipa server, shutdown its dirsrv daemon down so that you > can reset the attribute responsible for the serial generation, and so > that you can re-initialize its db from the known good ldif > On the master supplier: > ipactl stop > > > ? 3: Sanitize the dse.ldif Configuration File > On the master supplier: > edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the > nsState attribute from the replica config entry > You DO NOT want to remove the nsState from: dn: cn=uniqueid > generator,cn=config > > The stanza you want to remove the value from is: dn: > cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > The attribute will look like this: nsState:: > cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== > Delete the entire line > > ? 3.1: Remove traces of stale CSN tracking in the Replica Agreements > themeselves > File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; > d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif > backup the old dse.ldif and replace it with the new one: > # mv dse.ldif dse.saved.ldif > # mv new.dse.ldif dse.ldif > > ? 4: Import the data from the known good ldif. This will mark all the > changes with CSNs that match the current time/date stamps > On the master supplier: > chmod 644 /tmp/master-389.ldif > /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i > /tmp/master-389.ldif > > ? 5: Restart the ipa daemons on the master supplier > #ipactl start > > ? 6: When the daemon starts, it will see that it does not have an > nsState and will write new CSN's to -all- of the newly imported good > data with today's timetamp, we need to take that data and write -it- > out to an ldif file > On the master supplier: > /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory > Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif > ^ the -r tells it to include all replica data which includes the > newly blessed CSN data > transfer the file to all of the ipa servers in the fleet > > ? 7: Now we must re-initialize _every other_ ipa consumer server in > the fleet with the new good data. > Steps 7-10 need to be done 1 at a time on each ipa consumer server > ipactl stop > > ? 8: Sanitize the dse.ldif Configuration File > On the ipa server: > edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the > nsState attribute from the replica config entry > You DO NOT want to remove the nsState from: dn: cn=uniqueid > generator,cn=config > The stanza you want to remove the value from is: dn: > cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config > The attribute will look like this: nsState:: > cwAAAAAAAAA3QPBSAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== > Delete the entire line > > ? 8.1: Remove traces of stale CSN tracking in the Replica Agreements > themeselves > File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; > d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv > new.dse.ldif > backup the old dse.ldif and replace it with the new one > # mv dse.ldif dse.saved.ldif > # mv new.dse.ldif dse.ldif > > ? 9: Import the data from the known good ldif. This will mark all the > changes with CSNs that match the current time/date stamps > On the auth server: > chmod 644 /tmp/replication-master-389.ldif > /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i > /tmp/replication-master-389.ldif > > ? 10: Restart the ipa daemons on the ipa server > On the ipa server: > ipactl start > > > -------------------------------- > > From Rich Megginson: > Further reading for those interested in the particulars of CSN > tracking or the MultiMaster Replication algorithm, you can read up > about it here: > > It all starts with the Leslie Lamport paper: > http://www.stanford.edu/class/cs240/readings/lamport.pdf > "Time, Clocks, and the Ordering of Events in a Distributed System" > > The next big impact on MMR protocols was the work done at Xerox PARC > on the Bayou project. > > These and other sources formed the basis of the IETF LDUP working > group. Much of the MMR protocol is based on the LDUP work. > > > The tl;dr version is this: > > The MMR protocol is based on ordering operations by time so that when > you have two updates to the same attribute, the "last one wins" > So how do you guarantee some sort of consistent ordering throughout > many systems that do not have clocks in sync down to the millisecond? > If you say "ntp" then you lose... > The protocol itself has to have some notion of time differences among > servers > The ordering is done by CSN (Change Sequence Number) > The first part of the CSN is the timestamp of the operation in unix > time_t (number of seconds since the epoch). > In order to guarantee ordering, the MMR protocol has a major constraint > You must never, never, issue a CSN that is the same or less than > another CSN > In order to guarantee that, the MMR protocol keeps track of the time > differences among _all_ of the servers that it knows about. > When it generates CSNs, it uses the largest time difference among all > servers that it knows about. > > So how does the time skew grow at all? > Due to timing differences, network latency, etc. the directory server > cannot always generate the absolute exact system time. There will > always be 1 or 2 second differences in some replication sessions. > These 1 to 2 second differences accumulate over time. > > However, there are things which can introduce really large differences > 1) buggy ntp implementations > 2) bad sysadmin screws up the system clock > 3) vms which are notorious for having laggy system clocks, etc. > > > How can you monitor for this in the future? > The readnsState.py script supplied in this email can be used to output > the effective skew of the system date vs the CSN generator. > You can set a crontab to run this script and monitor its output to > catch any future severe drifts. > > Ticket information for some of the fixes that have been implimented > because of this work so far: > https://fedorahosted.org/389/ticket/47516 > > > > "You cannot hope to secure that which you do not first understand" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > JR Aquino > > Senior Information Security Specialist, Technical Operations > T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 > GIAC Certified Exploit Researcher and Advanced Penetration Tester | > GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler > JR.Aquino at citrix.com > > > > Powering mobile workstyles and cloud services -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 15835 bytes Desc: not available URL: From bnordgren at fs.fed.us Fri Feb 28 14:42:21 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 28 Feb 2014 14:42:21 +0000 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20140227224931.GV27086@hendrix.brq.redhat.com> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> > Caching credentials is disabled by default[1]. Even when credential caching is > enabled, the cache is only ever readable by root, the hashes are > *never* exposed to the system. FYI, the hash is a salted sha512. Ah. Much better. > What leads you to believe the cached credentials can be retrieved? --- RedHat sssd documentation from [2] --- Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. ---End RedHat sssd documentation from [2] --- Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From simo at redhat.com Fri Feb 28 14:56:26 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 28 Feb 2014 09:56:26 -0500 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129131101.GV21264@redhat.com> <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <1393599386.22047.8.camel@willson.li.ssimo.org> On Fri, 2014-02-28 at 14:42 +0000, Nordgren, Bryce L -FS wrote: > > Caching credentials is disabled by default[1]. Even when credential caching is > > enabled, the cache is only ever readable by root, the hashes are > > *never* exposed to the system. FYI, the hash is a salted sha512. > > Ah. Much better. > > > What leads you to believe the cached credentials can be retrieved? > > --- RedHat sssd documentation from [2] --- > Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. > ---End RedHat sssd documentation from [2] --- > > Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. > > [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm Offline password caching is also optional and a different method. In this case the actual password is maintained in the kernel keyring in locked memory until the machine goes online and can acquire a TGT. On success it is deleted. however it doesn't really matter from an evil-root scenario, because evil-root will have already snatched the password from the PAM stack at authentication time. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Fri Feb 28 15:11:49 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 28 Feb 2014 16:11:49 +0100 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <1393599386.22047.8.camel@willson.li.ssimo.org> References: <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> <1393599386.22047.8.camel@willson.li.ssimo.org> Message-ID: <20140228151149.GD29315@hendrix.brq.redhat.com> On Fri, Feb 28, 2014 at 09:56:26AM -0500, Simo Sorce wrote: > On Fri, 2014-02-28 at 14:42 +0000, Nordgren, Bryce L -FS wrote: > > > Caching credentials is disabled by default[1]. Even when credential caching is > > > enabled, the cache is only ever readable by root, the hashes are > > > *never* exposed to the system. FYI, the hash is a salted sha512. > > > > Ah. Much better. > > > > > What leads you to believe the cached credentials can be retrieved? > > > > --- RedHat sssd documentation from [2] --- > > Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials. > > ---End RedHat sssd documentation from [2] --- > > > > Presumably VPN does not accept a hash. Even if it does, gaining access to the hash gains you admission to the network as someone else. > > > > [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm > > > Offline password caching is also optional and a different method. > In this case the actual password is maintained in the kernel keyring in > locked memory until the machine goes online and can acquire a TGT. On > success it is deleted. > > however it doesn't really matter from an evil-root scenario, because > evil-root will have already snatched the password from the PAM stack at > authentication time. > > Simo. Right, just for completeness, the option that Simo describes is called krb5_store_password_if_offline. From sakodak at gmail.com Fri Feb 28 17:10:41 2014 From: sakodak at gmail.com (KodaK) Date: Fri, 28 Feb 2014 11:10:41 -0600 Subject: [Freeipa-users] TLS error on master server / CA issue? Message-ID: Hey everyone, A couple of days ago I started getting the following message: [jebalicki at slpidml01 ~]$ ipa cert-show 1 ipa: INFO: trying https://slpidml01.unix.xxx.com/ipa/xml ipa: INFO: Forwarding 'cert_show' to server u' https://slpidml01.unix.xxx.com/ipa/xml' ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) I get a similar error in the GUI when looking at hosts. slpidml01 is my "master" -- the one I initially built. The other replicas also replicated the CA. After some digging (and prompting from Red Hat support) I've found the following: [root at slpidml01 ~]# ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com -D "cn=Directory Manager" -W -b "dc=unix,dc=xxx,dc=com" -x ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. But, interestingly, from another replica: [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com -D "cn=Directory Manager" -W -b "dc=unix,dc=xxx,dc=com" -x Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL ... So, obviously some certificate got hosed up somewhere. I've been digging but I haven't found it yet. Anyone have any ideas? I have a ticket open with RH support, but I think I somehow got put with someone with a completely different sleep schedule -- I get replies at 3 in the morning. So, I'm asking here because I'm impatient. :) Thanks, --Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 28 17:14:25 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 12:14:25 -0500 Subject: [Freeipa-users] TLS error on master server / CA issue? In-Reply-To: References: Message-ID: <5310C3F1.9090703@redhat.com> KodaK wrote: > Hey everyone, > > A couple of days ago I started getting the following message: > > [jebalicki at slpidml01 ~]$ ipa cert-show 1 > ipa: INFO: trying https://slpidml01.unix.xxx.com/ipa/xml > ipa: INFO: Forwarding 'cert_show' to server > u'https://slpidml01.unix.xxx.com/ipa/xml' > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Not Found) > > I get a similar error in the GUI when looking at hosts. > > slpidml01 is my "master" -- the one I initially built. The other > replicas also replicated the CA. > > After some digging (and prompting from Red Hat support) I've found the > following: > > [root at slpidml01 ~]# ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com > -D "cn=Directory Manager" -W -b > "dc=unix,dc=xxx,dc=com" -x > ldap_start_tls: Connect error (-11) > additional info: TLS error -8172:Peer's certificate issuer has > been marked as not trusted by the user. > > But, interestingly, from another replica: > > [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com > -D "cn=Directory Manager" -W -b > "dc=unix,dc=xxx,dc=com" -x > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > ... > > So, obviously some certificate got hosed up somewhere. I've been > digging but I haven't found it yet. > > Anyone have any ideas? > > I have a ticket open with RH support, but I think I somehow got put with > someone with a completely different sleep schedule -- I get replies at 3 > in the morning. So, I'm asking here because I'm impatient. :) Check certificate expiration. Run getcert list to see what the status is. rob From bnordgren at fs.fed.us Fri Feb 28 17:27:55 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 28 Feb 2014 17:27:55 +0000 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <20140228151149.GD29315@hendrix.brq.redhat.com> References: <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> <1393599386.22047.8.camel@willson.li.ssimo.org> <20140228151149.GD29315@hendrix.brq.redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E691319@001FSN2MPN1-045.001f.mgd2.msft.net> > > Offline password caching is also optional and a different method. > > In this case the actual password is maintained in the kernel keyring > > in locked memory until the machine goes online and can acquire a TGT. > > On success it is deleted. > > > > however it doesn't really matter from an evil-root scenario, because > > evil-root will have already snatched the password from the PAM stack > > at authentication time. Ah. My evil root scenario was that my AS exchange happened on my trusted machine and I used SSO to sign in to Evil root's machine. No password in Evil's pam stack. Evil can log into an Evil-compromised machine all he wants. Can't steal a password from yourself. Please shoot holes in this design for me: :) A domain uses Kerberos for authentication. The domain does not allow LDAP or other forms of authentication. A domain has trusted, domain-administrated machines for initial sign on. Users are not given root access on these machines. Alternatively, users who have been given root access to a machine can initiate an AS exchange from machines they control, but others cannot and/or are strongly discouraged from doing so. Hence, a user can be granted control over their own workstation/laptop. Users are given permissions on machines as needed to configure whatever it is that they need to do. Say there is some sort of project with specialized requirements which affects ~10-50 participants or so. Someone in the project stands up a machine to address the project's needs, but this person is not part of the Organization, so he could be Evil. Users would be expected to perform their initial sign on using their own workstation/terminal, then connect to the project resource. Ideally, the project resource is a website of some type, so only a Kerberos service ticket is needed. In the case that project members need command line access, but no access to domain-wide services (like NFS server), they can just get a service ticket for host/evil.example.org at EXAMPLE.ORG. So far, Evil is boxed in. Evil has not been given credentials which allow him to impersonate another user to the domain. Evil's box is a black hole. Identities go in, but they can't get out. A problem occurs when users need to access domain-wide services from Evil's machine. The user (Innocent) can forward their TGT to Evil's machine, giving Evil full use of Innocent's identity, or Innocent can use their own, trusted workstation to individually request proxy tickets for the services Innocent intends to access. Evil can now impersonate Innocent. In the case where Evil received proxy tickets, it can only impersonate Innocent to specific services on specific hosts. In the case where Evil received a TGT, Evil can impersonate innocent at will to any domain service. This suggests that it should be a security requirement for non-organization-wide projects to provide their own services. This permits encouraging/mandating the use of service tickets with project resources. For instance, if the project needs file storage, they should provide file storage. Alternatively, if the organization wishes to provide storage, they may want to allocate servers (and Kerberos principals) individually for each project. This seems to me to be a way to compartmentalize groups of cooperating users in a way that tends to prevent Evil in one group from spreading to another group, while allowing users to leverage the organization's identity store...It seems to me that this is even more effective at stopping the spread of Evil than establishing hierarchical cross-realm trusts underneath the main organization... Am I overlooking something, or is this likely to be an effective means of delegating small project support while sideboarding potential Evil? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From JR.Aquino at citrix.com Fri Feb 28 18:03:29 2014 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 28 Feb 2014 18:03:29 +0000 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E691319@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> <1393599386.22047.8.camel@willson.li.ssimo.org> <20140228151149.GD29315@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E691319@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: Some further reading material about operating in a security model where you accept that things are already compromised: * CISecurity did a good job on the Kerberos benchmark that was written: http://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=mitkerberos110.100 * Two Factor should be employed on any system you consider critical: As far as Identities go, The Password is Dead... YubiKey is a pretty good, low overhead starting point, http://wiki.yubico.com/wiki/index.php/Main_Page * Long Live POSIX, the owner,group,everyone model has been broken for quite sometime. I suggest checking out Capsicum in addition to any further reading about trusted computing or SElinux, etc. http://www.cl.cam.ac.uk/research/security/capsicum/ https://github.com/google/capsicum-linux On Feb 28, 2014, at 9:27 AM, Nordgren, Bryce L -FS wrote: > >>> Offline password caching is also optional and a different method. >>> In this case the actual password is maintained in the kernel keyring >>> in locked memory until the machine goes online and can acquire a TGT. >>> On success it is deleted. >>> >>> however it doesn't really matter from an evil-root scenario, because >>> evil-root will have already snatched the password from the PAM stack >>> at authentication time. > > Ah. My evil root scenario was that my AS exchange happened on my trusted machine and I used SSO to sign in to Evil root's machine. No password in Evil's pam stack. Evil can log into an Evil-compromised machine all he wants. Can't steal a password from yourself. > > Please shoot holes in this design for me: :) > > A domain uses Kerberos for authentication. The domain does not allow LDAP or other forms of authentication. > > A domain has trusted, domain-administrated machines for initial sign on. Users are not given root access on these machines. Alternatively, users who have been given root access to a machine can initiate an AS exchange from machines they control, but others cannot and/or are strongly discouraged from doing so. Hence, a user can be granted control over their own workstation/laptop. > > Users are given permissions on machines as needed to configure whatever it is that they need to do. Say there is some sort of project with specialized requirements which affects ~10-50 participants or so. Someone in the project stands up a machine to address the project's needs, but this person is not part of the Organization, so he could be Evil. > > Users would be expected to perform their initial sign on using their own workstation/terminal, then connect to the project resource. Ideally, the project resource is a website of some type, so only a Kerberos service ticket is needed. In the case that project members need command line access, but no access to domain-wide services (like NFS server), they can just get a service ticket for host/evil.example.org at EXAMPLE.ORG. > > So far, Evil is boxed in. Evil has not been given credentials which allow him to impersonate another user to the domain. Evil's box is a black hole. Identities go in, but they can't get out. > > A problem occurs when users need to access domain-wide services from Evil's machine. The user (Innocent) can forward their TGT to Evil's machine, giving Evil full use of Innocent's identity, or Innocent can use their own, trusted workstation to individually request proxy tickets for the services Innocent intends to access. > > Evil can now impersonate Innocent. In the case where Evil received proxy tickets, it can only impersonate Innocent to specific services on specific hosts. In the case where Evil received a TGT, Evil can impersonate innocent at will to any domain service. > > This suggests that it should be a security requirement for non-organization-wide projects to provide their own services. This permits encouraging/mandating the use of service tickets with project resources. For instance, if the project needs file storage, they should provide file storage. Alternatively, if the organization wishes to provide storage, they may want to allocate servers (and Kerberos principals) individually for each project. > > This seems to me to be a way to compartmentalize groups of cooperating users in a way that tends to prevent Evil in one group from spreading to another group, while allowing users to leverage the organization's identity store...It seems to me that this is even more effective at stopping the spread of Evil than establishing hierarchical cross-realm trusts underneath the main organization... > > Am I overlooking something, or is this likely to be an effective means of delegating small project support while sideboarding potential Evil? > > Bryce > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sakodak at gmail.com Fri Feb 28 18:31:56 2014 From: sakodak at gmail.com (KodaK) Date: Fri, 28 Feb 2014 12:31:56 -0600 Subject: [Freeipa-users] TLS error on master server / CA issue? In-Reply-To: <5310C3F1.9090703@redhat.com> References: <5310C3F1.9090703@redhat.com> Message-ID: On Fri, Feb 28, 2014 at 11:14 AM, Rob Crittenden wrote: > KodaK wrote: > >> Hey everyone, >> >> A couple of days ago I started getting the following message: >> >> [jebalicki at slpidml01 ~]$ ipa cert-show 1 >> ipa: INFO: trying https://slpidml01.unix.xxx.com/ipa/xml >> ipa: INFO: Forwarding 'cert_show' to server >> u'https://slpidml01.unix.xxx.com/ipa/xml' >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (Not Found) >> >> I get a similar error in the GUI when looking at hosts. >> >> slpidml01 is my "master" -- the one I initially built. The other >> replicas also replicated the CA. >> >> After some digging (and prompting from Red Hat support) I've found the >> following: >> >> [root at slpidml01 ~]# ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com >> -D "cn=Directory Manager" -W -b >> >> "dc=unix,dc=xxx,dc=com" -x >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8172:Peer's certificate issuer has >> been marked as not trusted by the user. >> >> But, interestingly, from another replica: >> >> [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H ldap://slpidml01.unix.xxx.com >> -D "cn=Directory Manager" -W -b >> >> "dc=unix,dc=xxx,dc=com" -x >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> ... >> >> So, obviously some certificate got hosed up somewhere. I've been >> digging but I haven't found it yet. >> >> Anyone have any ideas? >> >> I have a ticket open with RH support, but I think I somehow got put with >> someone with a completely different sleep schedule -- I get replies at 3 >> in the morning. So, I'm asking here because I'm impatient. :) >> > > Check certificate expiration. Run getcert list to see what the status is. > > rob > > None are expired, but there are some coming up soon: [root at slpidml01 ~]# getcert list | grep expires expires: 2014-03-29 19:03:31 UTC expires: 2014-03-29 19:04:04 UTC expires: 2014-03-29 19:04:30 UTC expires: 2016-02-09 06:26:34 UTC expires: 2016-02-09 06:25:34 UTC expires: 2016-02-09 06:25:34 UTC expires: 2016-02-09 06:25:34 UTC expires: 2016-02-09 06:25:34 UTC Everything is set to auto-renew: [root at slpidml01 ~]# getcert list | grep auto-renew auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes auto-renew: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Feb 28 18:46:31 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 28 Feb 2014 13:46:31 -0500 Subject: [Freeipa-users] local root can su to any IPA user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E691319@001FSN2MPN1-045.001f.mgd2.msft.net> References: <20131129134829.GA4430@hendrix.redhat.com> <20131129141711.GE4430@hendrix.redhat.com> <5298A78C.1090400@redhat.com> <20140227200644.GP27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69104B@001FSN2MPN1-045.001f.mgd2.msft.net> <20140227224931.GV27086@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E69122F@001FSN2MPN1-045.001f.mgd2.msft.net> <1393599386.22047.8.camel@willson.li.ssimo.org> <20140228151149.GD29315@hendrix.brq.redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E691319@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <1393613191.22047.13.camel@willson.li.ssimo.org> On Fri, 2014-02-28 at 17:27 +0000, Nordgren, Bryce L -FS wrote: > Am I overlooking something, or is this likely to be an effective means > of delegating small project support while sideboarding potential Evil? Well, there area always caveats, mostly that you will find exceptions you have to permit for whatever reason, so you generally need a workable exception mechanism when that happens, auditing can be a suitable mitigation factor in those cases. That said I think JR also gave excellent points. Esp wrt 2FA which, incidentally, we are almost done implementing in FreeIPA. With 2FA you substantially reduce the threat of stolen passwords, when you have to allow password login on less trusted machines, at least for human accounts. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Feb 28 19:05:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Feb 2014 14:05:56 -0500 Subject: [Freeipa-users] TLS error on master server / CA issue? In-Reply-To: References: <5310C3F1.9090703@redhat.com> Message-ID: <5310DE14.1020105@redhat.com> KodaK wrote: > > > > On Fri, Feb 28, 2014 at 11:14 AM, Rob Crittenden > wrote: > > KodaK wrote: > > Hey everyone, > > A couple of days ago I started getting the following message: > > [jebalicki at slpidml01 ~]$ ipa cert-show 1 > ipa: INFO: trying https://slpidml01.unix.xxx.__com/ipa/xml > > ipa: INFO: Forwarding 'cert_show' to server > u'https://slpidml01.unix.xxx.__com/ipa/xml > ' > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Not Found) > > I get a similar error in the GUI when looking at hosts. > > slpidml01 is my "master" -- the one I initially built. The other > replicas also replicated the CA. > > After some digging (and prompting from Red Hat support) I've > found the > following: > > [root at slpidml01 ~]# ldapsearch -ZZ -H > ldap://slpidml01.unix.xxx.com > -D "cn=Directory Manager" -W -b > > "dc=unix,dc=xxx,dc=com" -x > ldap_start_tls: Connect error (-11) > additional info: TLS error -8172:Peer's certificate > issuer has > been marked as not trusted by the user. > > But, interestingly, from another replica: > > [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H > ldap://slpidml01.unix.xxx.com > -D "cn=Directory Manager" -W -b > > "dc=unix,dc=xxx,dc=com" -x > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > ... > > So, obviously some certificate got hosed up somewhere. I've been > digging but I haven't found it yet. > > Anyone have any ideas? > > I have a ticket open with RH support, but I think I somehow got > put with > someone with a completely different sleep schedule -- I get > replies at 3 > in the morning. So, I'm asking here because I'm impatient. :) > > > Check certificate expiration. Run getcert list to see what the > status is. > > rob > > > None are expired, but there are some coming up soon: > > [root at slpidml01 ~]# getcert list | grep expires > expires: 2014-03-29 19:03:31 UTC > expires: 2014-03-29 19:04:04 UTC > expires: 2014-03-29 19:04:30 UTC > expires: 2016-02-09 06:26:34 UTC > expires: 2016-02-09 06:25:34 UTC > expires: 2016-02-09 06:25:34 UTC > expires: 2016-02-09 06:25:34 UTC > expires: 2016-02-09 06:25:34 UTC Ok. CA requests are proxied through Apache so a Not Found means that the CA isn't running. Check the trust on the audit cert: # certutil -L -d /var/lib/pki-ca/alias The trust for the audit signing cert should be u,u,Pu If it doesn't have it, fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA (or all of IPA if you wish). For the LDAP searches you may want to try the commands again, preceding them with LDAPTLS_CACERT=/etc/ipa/ca.crt rob From sakodak at gmail.com Fri Feb 28 20:17:37 2014 From: sakodak at gmail.com (KodaK) Date: Fri, 28 Feb 2014 14:17:37 -0600 Subject: [Freeipa-users] [solved] TLS error on master server / CA issue? Message-ID: On Fri, Feb 28, 2014 at 1:05 PM, Rob Crittenden wrote: > KodaK wrote: > >> >> >> >> On Fri, Feb 28, 2014 at 11:14 AM, Rob Crittenden > > wrote: >> >> KodaK wrote: >> >> Hey everyone, >> >> A couple of days ago I started getting the following message: >> >> [jebalicki at slpidml01 ~]$ ipa cert-show 1 >> ipa: INFO: trying https://slpidml01.unix.xxx.__com/ipa/xml >> >> >> ipa: INFO: Forwarding 'cert_show' to server >> u'https://slpidml01.unix.xxx.__com/ipa/xml >> >> ' >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (Not Found) >> >> I get a similar error in the GUI when looking at hosts. >> >> slpidml01 is my "master" -- the one I initially built. The other >> replicas also replicated the CA. >> >> After some digging (and prompting from Red Hat support) I've >> found the >> following: >> >> [root at slpidml01 ~]# ldapsearch -ZZ -H >> ldap://slpidml01.unix.xxx.com >> -D "cn=Directory Manager" -W -b >> >> >> "dc=unix,dc=xxx,dc=com" -x >> ldap_start_tls: Connect error (-11) >> additional info: TLS error -8172:Peer's certificate >> issuer has >> been marked as not trusted by the user. >> >> But, interestingly, from another replica: >> >> [jebalicki at slpidml02 ~]$ ldapsearch -ZZ -H >> ldap://slpidml01.unix.xxx.com >> -D "cn=Directory Manager" -W -b >> >> >> "dc=unix,dc=xxx,dc=com" -x >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> ... >> >> So, obviously some certificate got hosed up somewhere. I've been >> digging but I haven't found it yet. >> >> Anyone have any ideas? >> >> I have a ticket open with RH support, but I think I somehow got >> put with >> someone with a completely different sleep schedule -- I get >> replies at 3 >> in the morning. So, I'm asking here because I'm impatient. :) >> >> >> Check certificate expiration. Run getcert list to see what the >> status is. >> >> rob >> >> >> None are expired, but there are some coming up soon: >> >> [root at slpidml01 ~]# getcert list | grep expires >> expires: 2014-03-29 19:03:31 UTC >> expires: 2014-03-29 19:04:04 UTC >> expires: 2014-03-29 19:04:30 UTC >> expires: 2016-02-09 06:26:34 UTC >> expires: 2016-02-09 06:25:34 UTC >> expires: 2016-02-09 06:25:34 UTC >> expires: 2016-02-09 06:25:34 UTC >> expires: 2016-02-09 06:25:34 UTC >> > > Ok. CA requests are proxied through Apache so a Not Found means that the > CA isn't running. Check the trust on the audit cert: > > # certutil -L -d /var/lib/pki-ca/alias > > The trust for the audit signing cert should be u,u,Pu > > If it doesn't have it, fix it with: > > # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' > -t u,u,Pu > > Then restart the CA (or all of IPA if you wish). > > For the LDAP searches you may want to try the commands again, preceding > them with LDAPTLS_CACERT=/etc/ipa/ca.crt > rob > > Thanks a bunch, that worked! -------------- next part -------------- An HTML attachment was scrubbed... URL: