Steps to reproduce:

1. Set up an IPA realm with at least two servers (one replicating to the other) providing DNS. (We'll call them master and secondary).

2. Create a client and set its FQDN hostname to something OTHER than hostname.ipa.domain. For example, if the IPA domain is "ipa.com", set the client hostname to "client.example.com"

2. Enroll a client against the master. Disable cached credentials by setting cache_credentials = False in sssd.conf (This is so we can ensure that we're testing against the server)

3. Take down the master.

X. Set /etc/resolv.conf to point at the secondary (or don't. This step just avoids the timeout trying to reach the primary DNS)

4. Attempt to log in to the client.

Before this fix, we would fail because we cannot look up the server entries from DNS (our DNS lookup would be trying to find _ldap._tcp.example.com, but it SHOULD be looking for _ldap._tcp.ipa.com).

After this fix, lookups will be against the correct DNS domain and login should succeed.

Verified.

sssd-version:
============

[root@dhcp201-113 ~]# rpm -q sssd
sssd-1.8.0-25.el6.x86_64
[root@dhcp201-113 ~]#

Followed steps given in comment 2 for verification.

DNS lookup tries for _ldap._tcp.testrelm.com and login is also successful.

[root@dhcp201-113 ~]# hostname
dhcp201-113.englab.pnq.redhat.com
[root@dhcp201-113 ~]#

[root@dhcp201-113 ~]# cat /var/log/sssd/sssd_testrelm.com.log |grep _ldap._tcp 
(Wed May  9 19:12:54 2012) [sssd[be[testrelm.com]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_ldap._tcp.testrelm.com'
(Wed May  9 19:12:54 2012) [sssd[be[testrelm.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.testrelm.com'
[root@dhcp201-113 ~]#

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: SSSD would use either the value of dns_discovery_domain or else the hostname portion of the machine's FQDN to look up DNS SRV records for failover servers.

Consequence: On FreeIPA-enrolled machines, the client hostname might not match the IPA domain name. These clients would be unable to discover failover servers.

Change: When id_provider = ipa, dns_discovery_domain will be automatically set to the value if ipa_domain.

Result: FreeIPA clients will be able to autodetect failover servers even if their hostname is not part of the FreeIPA domain.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0747.html

This is not a good idea!

If a user does not have SRV records for the domain their systems are in, then we should create them, or encourage the users to create them. Maybe we can provide an option in ipa-client-install for the dns_discovery_domain.

This broke our implementation of IPA, because now we have hosts that are not pointing to the correct DNS subdomains for SRV record lookups. In an enterprise environment, you want to segregate IPA domains, for instance, so that software development environments cannot affect production environments. Having this default encourages that all IPA servers exist in one pool, rather than facilitating the segregation of resources, as is proper.