[Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers

Tue Mar 10 08:58:07 UTC 2015

On Mon, Mar 9, 2015 at 9:49 PM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
> On Mon, 09 Mar 2015, Traiano Welcome wrote:
>>
>> Hi Alexander
>>
>> Thanks for the response:
>>
>> On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy <abokovoy at redhat.com>
>> wrote:
>>>
>>> On Mon, 09 Mar 2015, Traiano Welcome wrote:
>>>>
>>>>
>>>> Hi List
>>>>
>>>>
>>>> I have AD trusts configured and working between an IPA server and a
>>>> "master" primary domain controller (dc-1) in a forest in one data
>>>> center. This allows me to connect with SSH to linux servers in the
>>>> same data-center, authenticating with my AD credentials.
>>>>
>>>> I'm trying to test a scenario where I have an IPA server set up in
>>>> another data center, and trust is established with an AD domain
>>>> controller (dc-2) in that data-center.
>>>> This domain controller takes dc-1 as it's authoritative source.
>>>> Ideally, the IPA server will interact with the domain controller
>>>> nearest to it (i.e dc-2), however, from tcpdump, I note the following:
>>>>
>>>> - IPA server communicates with dc-2 first
>>>> - dc-2 returns a list of domain controllers in all the datacenters,
>>>> including dc-1
>>>> the IPA server then begins querying ldap and kerberos ports on dc-1,
>>>> the domain controller furthest from it.
>>>> - Authentication on clients fail
>>>>
>>>> My question is:  Is it possible to get IPA  to query and interact only
>>>> with the domain controller it initially established trust with?
>>>
>>>
>>> Let's first separate multiple issues.
>>>
>>> 1. Terminology
>>>   Cross-forest trust is established between domain controllers in forest
>>> root
>>>   domains. In case of IPA we need that access only once, when trust is
>>>   created. You don't need to establish trust again with dc-2 once you
>>>   have established it with dc-1.
>>>
>>>   When trust is established, AD DCs will look up IPA masters via SRV
>>>   records in DNS (_ldap._tcp.<ipa-domain>). We don't provide
>>>   site-specific SRV records as IPA does not handle sites in this area
>>>   yet.
>>>
>>
>>
>> Thanks for the clarification.
>>
>>
>>>   However, this is not your problem.
>>>
>>> 2. User and group lookups are done by SSSD against global catalog
>>>   service (_gc._tcp.<ad-domain>) and AD DS (_ldap._tcp.<ad-domain>),
>>>   along with Kerberos KDC (AD DCs).
>>>
>>>   These DCs are found via SRV records in DNS and SSSD since 1.9.5
>>>   uses site-specific SRV records for AD domain controllers lookups in
>>>   case of IPA-AD trust.
>>>
>>> You are interested in (2) being site-aware. However, you didn't say what
>>> is your distribution and software versions so it is quite hard to give
>>> any recommendation.
>>
>>
>> My objective is basically distribution of IPA servers across multiple
>> data centers linked by a WAN:
>>
>> - There is a central 'head office' with an AD domain-controller, this
>> is the primary source of identity for the domain.
>> - A number of other data-centers each have their own local AD domain
>> controller linked to the head-office domain controller
>> - The datacenters are in different timezones.
>> - An IPA server in each data-center with trust established with the
>> local domain controller
>> - Each IPA server is configured with it's own realm, but provides
>> access to the global AD domain via AD Trusts
>>
>> The idea was to prevent IPA authentication related traffic going
>> across the WAN (latency, different time-zones etc) to a central ad
>> domain controller at head office. So this setup seemed reasonable.
>
> Do you have sites defined in AD?

Yes. It seems AD is configured to be site aware and to respond to IPA
with the site-specific ad domain controller.

>
> If so, can you enable debug_level=10 in /etc/sssd/sssd.conf on IPA master
> in the other datacenter and attempt to login as AD user. We'll see in
> SSSD logs how it discovers what AD DC to talk to.
>
> Add following to /etc/sssd/sssd.conf:
> [domain/..]
> ..
> debug_level = 10
>
> [nss]
> debug_level = 10
>
> and restart sssd.

Done. Looking at the logs, discovery seems to be working correctly
now, and it seems to be using the site-specific dc AD hands to it (see
attached log sssd_idmlol.local.log_sanitized.txt ):

---
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_srv_plugin_send]
(0x0400): About to find domain controllers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_get_dc_servers_send] (0x0400): Looking up domain controllers in
domain yyy.com
.
.
.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_discover_srv_done] (0x0400): Got answer. Processing...
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_discover_srv_done] (0x0400): Got 5 servers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_get_dc_servers_done] (0x0400): Found 5 domain controllers in
domain yyy.com
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_srv_plugin_dcs_done] (0x0400): About to locate suitable site
.
.
.

(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[be_get_account_info] (0x0100): Got request for
[4098][1][name=traiano]
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [be_req_set_domain]
(0x0400): Changing request domain from [idmdc2.com] to [yyy.com]
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_id_op_connect_step] (0x4000): waiting for connection to complete
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout
watcher
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[request_watch_destructor] (0x0400): Deleting request watch
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_connect_host_resolv_done] (0x0400): Connecting to
ldap://loldc001.yyy.com:389
.
.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to
[ldap://loldc001.yyy.com:389/??base] with fd [24].
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_connect_host_done] (0x0400): Successful connection to
ldap://loldc001.yyy.com:389
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(DnsDomain=yyy.com)(NtVer=\14\00\00\00))][].
.
.

(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_get_client_site_done] (0x0400): Found site: LOL-DC2
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_srv_plugin_site_done] (0x0400): About to discover primary and
backup servers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_discover_servers_send] (0x0400): Looking up primary servers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_discover_srv_next_domain] (0x0400): SRV resolution of service
'ldap'. Will use DNS discovery domain 'LOL-DC2._sites.yyy.com'
.
.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_discover_srv_done] (0x0400): Got 5 servers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_srv_plugin_servers_done] (0x0400): Got 1 primary and 5 backup
servers
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted primary server
'loldc004.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted backup server
'site_x_dc001.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted backup server
'site_x_dc002.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted backup server
'site_z_dc002.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted backup server
'loldc002.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[fo_add_server_to_list] (0x0400): Inserted backup server
'loldc001.yyy.com:389' to service 'yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[set_srv_data_status] (0x0100): Marking SRV lookup of service
'yyy.com' as 'resolved'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [get_server_status]
(0x1000): Status of server 'loldc004.yyy.com' is 'name not resolved'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_is_address]
(0x4000): [loldc004.yyy.com] does not look like an IP address
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_step] (0x2000): Querying files
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record
of 'loldc004.yyy.com' in files
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[set_server_common_status] (0x0100): Marking server 'loldc004.yyy.com'
as 'resolving name'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_step] (0x2000): Querying files
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA
record of 'loldc004.yyy.com' in files
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_next] (0x0200): No more address families to
retry
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_step] (0x2000): Querying DNS
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record
of 'loldc004.yyy.com' in DNS
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout
watcher
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[request_watch_destructor] (0x0400): Deleting request watch
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[set_server_common_status] (0x0100): Marking server 'loldc004.yyy.com'
as 'name resolved'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[be_resolve_server_process] (0x1000): Saving the first resolved server
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[be_resolve_server_process] (0x0200): Found address for server
loldc004.yyy.com: [172.16.200.122] TTL 3600
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_resolve_callback] (0x0100): Constructed uri
'ldap://loldc004.yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[ad_resolve_callback] (0x0100): Constructed GC uri
'ldap://loldc004.yyy.com'
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sss_ldap_init_send]
(0x4000): Using file descriptor [24] for LDAP connection.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sss_ldap_init_send]
(0x0400): Setting 6 seconds timeout for connecting
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to
[ldap://loldc004.yyy.com:389/??base] with fd [24].
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_get_rootdse_send] (0x4000): Getting rootdse
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(objectclass=*)][].
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*]

---

However, I'm still not able to authenticate via the ssh->sssd path (I
cn get kerberos tickets for ad users via cli though), so I think that
incorrect dc discovery is not really the issue here. Instead, it seem
the ldap query against the discovered AD domain controller is failing
with some kid of policy related error:

Here's a snippet what we're seeing in the IPA master sssd logs during
an a client connection attempt:

---
.
.
.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: gssapi, user:
host/lolospr-idm-mstr.idmdc2.com
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0020): ldap_sasl_bind failed (-2)[Local error]
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure.  Minor code may provide more
information (KDC policy rejects request)]
.
.

---

Further down I also  see this message which seems to indicate an issue
the IPA server has talking to the ldap port on the AD dc:

---
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [fo_set_port_status]
(0x0100): Marking port 389 of server 'loldc004.yyy.com' as 'not
working'
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [fo_set_port_status]
(0x0400): Marking port 389 of duplicate server 'loldc004.yyy.com' as
'not working'
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp]
(0x1000): Comparing LDAP with LDAP
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[sdap_handle_release] (0x2000): Trace: sh[0x7f8f2e9f0fb0],
connected[1], ops[(nil)], ldap[0x7f8f2e98f3f0], destructor_lock[0],
release_memory[0]
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[remove_connection_callback] (0x4000): Successfully removed connection
callback.
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [be_mark_offline]
(0x2000): Going offline!
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [be_run_offline_cb]
(0x0080): Going offline. Running callbacks.
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[sdap_id_op_connect_done] (0x4000): notify offline to op #1
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed
request
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[sdap_id_op_connect_done] (0x4000): notify offline to op #2
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed
request
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,11,Account info lookup failed
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]]
[sdap_id_release_conn_data] (0x4000): releasing unused connection

---

However, looking at tcpdump I see the communication between IPA server
and port 389 on the ad domain controller working fine (verbose tcpump
attached):

---
10:25:37.024424 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [S], seq 3511982115, win 14600, options
[mss 1460,sackOK,TS val 54616734 ecr 0,nop,wscale 7], length 0
10:25:37.024744 IP loldc004.yyy.com.ldap >
lolospr-idm-mstr.idmdc2.com.37537: Flags [S.], seq 785389569, ack
3511982116, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val
117103354 ecr 54616734], length 0
10:25:37.024811 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [.], ack 1, win 115, options [nop,nop,TS
val 54616735 ecr 117103354], length 0
10:25:37.025363 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [P.], seq 1:261, ack 1, win 115, options
[nop,nop,TS val 54616735 ecr 117103354], length 260
10:25:37.025746 IP loldc004.yyy.com.ldap >
lolospr-idm-mstr.idmdc2.com.37537: Flags [.], seq 1:1449, ack 261, win
514, options [nop,nop,TS val 117103355 ecr 54616735], length 1448
10:25:37.025793 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [.], ack 1449, win 137, options
[nop,nop,TS val 54616736 ecr 117103355], length 0
10:25:37.025808 IP loldc004.yyy.com.ldap >
lolospr-idm-mstr.idmdc2.com.37537: Flags [P.], seq 1449:2631, ack 261,
win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1182
10:25:37.025826 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [.], ack 2631, win 160, options
[nop,nop,TS val 54616736 ecr 117103355], length 0
10:25:39.087598 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [P.], seq 261:268, ack 2631, win 160,
options [nop,nop,TS val 54618797 ecr 117103355], length 7
10:25:39.087673 IP lolospr-idm-mstr.idmdc2.com.37537 >
loldc004.yyy.com.ldap: Flags [F.], seq 268, ack 2631, win 160, options
[nop,nop,TS val 54618798 ecr 117103355], length 0
10:25:39.087912 IP loldc004.yyy.com.ldap >
lolospr-idm-mstr.idmdc2.com.37537: Flags [.], ack 269, win 514,
options [nop,nop,TS val 117103561 ecr 54618797], length 0
10:25:39.087944 IP loldc004.yyy.com.ldap >
lolospr-idm-mstr.idmdc2.com.37537: Flags [R.], seq 2631, ack 269, win
0, length 0

---

... Given this, I'm not sure how to interpret the "port not working" message.

>
>
>> I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference,
>> the working setup was based on this howto:
>>
>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description
>>
>> ... which works fine if the IPA server has a trust relationship
>> directly with the primary domain controller at head office (which it
>> is collocated with).
>>
>> I can live without site-awareness per se if I can achieve IPA
>> centralised authentication across datacenters in different timezones,
>> with AD as the primary source of identity. An alternative setup that
>> I've considered testing:
>>
>> - IPA server at the head office with trust established to the primary AD
>> DC.
>> - A replica of the primary in each DC (different timezones), on the same
>> realm
>
> Currently each master has to be prepared with ipa-adtrust-install if any
> of IPA clients connected to this master need to be accessible to AD
> users.
>
> --
> / Alexander Bokovoy
-------------- next part --------------
[root at lolospr-idm-mstr sssd]# tcpdump -i ens192 port 389 and host loldc004.yyy.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes
10:25:37.024424 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [S], seq 3511982115, win 14600, options [mss 1460,sackOK,TS val 54616734 ecr 0,nop,wscale 7], length 0
10:25:37.024744 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [S.], seq 785389569, ack 3511982116, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 117103354 ecr 54616734], length 0
10:25:37.024811 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 0
10:25:37.025363 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 1:261, ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 260
10:25:37.025746 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], seq 1:1449, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1448
10:25:37.025793 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1449, win 137, options [nop,nop,TS val 54616736 ecr 117103355], length 0
10:25:37.025808 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [P.], seq 1449:2631, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1182
10:25:37.025826 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 2631, win 160, options [nop,nop,TS val 54616736 ecr 117103355], length 0
10:25:39.087598 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 261:268, ack 2631, win 160, options [nop,nop,TS val 54618797 ecr 117103355], length 7
10:25:39.087673 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [F.], seq 268, ack 2631, win 160, options [nop,nop,TS val 54618798 ecr 117103355], length 0
10:25:39.087912 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], ack 269, win 514, options [nop,nop,TS val 117103561 ecr 54618797], length 0
10:25:39.087944 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [R.], seq 2631, ack 269, win 0, length 0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: verbose_dump_389.log
Type: application/octet-stream
Size: 18809 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150310/93daf1ad/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_idmlol.local.log_sanitized
Type: application/octet-stream
Size: 51712 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150310/93daf1ad/attachment-0001.obj>