Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
Hi Alexander On Tue, Mar 10, 2015 at 12:08 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Tue, 10 Mar 2015, Traiano Welcome wrote: 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)] When AD says KDC policy rejects request it means that trust is not working well -- AD DC was unable to complete trust validation when it was established. See another emails around the trust last week or so, they have details on how to debug this. This is probably the case, however, I'd like to drill down further to see exactly what part of the trust is broken, because it seems the trust was established without error (using ipa trust-add), and I seem to be able to get trust information with ipa trust-show: Re-adding the trusts: --- [root@loldc2-idm-mstr ~]# ipa trust-add --type=ad lol.com --admin admin --password Active directory domain administrator's password: -- Re-established trust to domain lol.com -- Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root@loldc2-idm-mstr ~]# --- Using trust show: --- [root@loldc2-idm-mstr sssd]# ipa trust-show Realm name: LOL.COM Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 Trust direction: Two-way trust Trust type: Active Directory domain --- I can see that not all is well with the trusts because when I test with wbinfo, I get this: --- [root@loldc2-idm-mstr ~]# wbinfo --verbose -n 'LOL\Domain Admins' failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup name LOL\Domain Admins --- Looking at the samba logs with debug turned up, I get something potentially enlightening in the message NT_STATUS_ACCESS_DENIED ... However, the question is to pinpoint if this is due to an AD-side policy issue, or due to some weirdness on the IPA end of things: --- . . . [2015/03/10 17:02:46.934072, 3, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:69(winbindd_lookupname_send) lookupname LOL\Domain Admins [2015/03/10 17:02:46.934190, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName in: struct wbint_LookupName domain : * domain : 'LOL' name : * name : 'DOMAIN ADMINS' flags: 0x (0) [2015/03/10 17:02:46.934532, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event tevent_req_trigger: 0x7facefb10430 [2015/03/10 17:02:46.934696, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event tevent_req_trigger: 0x7facefb10430 [2015/03/10 17:02:46.934812, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName out: struct wbint_LookupName type : * type : SID_NAME_USE_NONE (0) sid : * sid : S-0-0
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Tue, 10 Mar 2015, Traiano Welcome wrote: Hi Alexander On Tue, Mar 10, 2015 at 12:08 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Tue, 10 Mar 2015, Traiano Welcome wrote: 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)] When AD says KDC policy rejects request it means that trust is not working well -- AD DC was unable to complete trust validation when it was established. See another emails around the trust last week or so, they have details on how to debug this. This is probably the case, however, I'd like to drill down further to see exactly what part of the trust is broken, because it seems the trust was established without error (using ipa trust-add), and I seem to be able to get trust information with ipa trust-show: In FreeIPA 3.3 we don't check the error code of validation process. We do in FreeIPA 4.1 so you need to use debug info in /var/log/httpd/error_log to find out -- like I wrote in other threads. Re-adding the trusts: --- [root@loldc2-idm-mstr ~]# ipa trust-add --type=ad lol.com --admin admin --password Active directory domain administrator's password: -- Re-established trust to domain lol.com -- Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root@loldc2-idm-mstr ~]# --- Using trust show: --- [root@loldc2-idm-mstr sssd]# ipa trust-show Realm name: LOL.COM Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 Trust direction: Two-way trust Trust type: Active Directory domain --- I can see that not all is well with the trusts because when I test with wbinfo, I get this: --- [root@loldc2-idm-mstr ~]# wbinfo --verbose -n 'LOL\Domain Admins' failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup name LOL\Domain Admins --- Looking at the samba logs with debug turned up, I get something potentially enlightening in the message NT_STATUS_ACCESS_DENIED ... However, the question is to pinpoint if this is due to an AD-side policy issue, or due to some weirdness on the IPA end of things: --- . . . [2015/03/10 17:02:46.934072, 3, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:69(winbindd_lookupname_send) lookupname LOL\Domain Admins [2015/03/10 17:02:46.934190, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName in: struct wbint_LookupName domain : * domain : 'LOL' name : * name : 'DOMAIN ADMINS' flags: 0x (0) [2015/03/10 17:02:46.934532, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event tevent_req_trigger: 0x7facefb10430 [2015/03/10 17:02:46.934696, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event tevent_req_trigger: 0x7facefb10430 [2015/03/10 17:02:46.934812, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName out: struct wbint_LookupName type
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, Mar 09, 2015 at 08:27:05PM -0400, Dmitri Pal wrote: On 03/09/2015 03:40 PM, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@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. 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 However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, Mar 9, 2015 at 9:49 PM, Alexander Bokovoy aboko...@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 aboko...@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
[Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
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? Thanks in advance, Traiano -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
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. 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. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@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. 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 However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. For AD DC the AD DNS will be returning the server to authenticate against and there should be a way to configure AD DNS this way. I do not think it is possible to force specific DNS entry out of IPA - it does not support sites yet. But may be there is a way to override it on SSSD. In case of other (legacy Linux or other platforms) clients that talk to IPA you can configure them with the explicit fail over list. They do not talk to AD directly. You might also consider configuring SSSD on the IPA server to use AD in the same location as a primary server. HTH --
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
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 aboko...@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? 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. 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@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. 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 However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains in a single back end. This is a known pain point me and Pavel Brezina were talking about for a long time.
Re: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
On 03/09/2015 03:40 PM, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@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. 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 However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains in a single back end. This is a known pain point me and Pavel Brezina were talking about for a long time. So far there hasn't been a driver that would justify
