Fields changed

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=743503

{{{
SSSD should support DNS "sites" concept known from Active Directory. Example:
Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
I have machine in Prague and I want it to join CONTOSO.COM. Now if I used:

dns_discovery_domain = contoso.com

sssd would try to connect to any DC in the domain - even the one in Dublin, completely ignoring sites.
I have to use:

dns_discovery_domain = Prague._sites.contoso.com

To force it to use Prague DCs only.
My understanding is, that the "DC locator" tries to communicate with DC's first to determine local site and remote DC's are only used if no valid/working DC can be found in the local site (Prague in this case).

This is AD specific functionality, but this concept would find its use also in large IPA domains where multiple IPA servers for the same domain exist in demographically different sites.

I believe some of the necessary code can be "stolen" from the Samba winbind component which implements this functionality
}}}
=> https://bugzilla.redhat.com/show_bug.cgi?id=743503

{{{
SSSD should support DNS "sites" concept known from Active Directory. Example:
Example AD domain CONTOSO.COM used on 3 sites - Prague,Cork, Dublin.
I have machine in Prague and I want it to join CONTOSO.COM. Now if I used:

dns_discovery_domain = contoso.com

sssd would try to connect to any DC in the domain - even the one in Dublin, completely ignoring sites.
I have to use:

dns_discovery_domain = Prague._sites.contoso.com

To force it to use Prague DCs only.
My understanding is, that the "DC locator" tries to communicate with DC's first to determine local site and remote DC's are only used if no valid/working DC can be found in the local site (Prague in this case).

This is AD specific functionality, but this concept would find its use also in large IPA domains where multiple IPA servers for the same domain exist in demographically different sites.

I believe some of the necessary code can be "stolen" from the Samba winbind component which implements this functionality
}}}

milestone: NEEDS_TRIAGE => SSSD 1.9.0
patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=743503 743503]

AD integration enhancements are critical for 1.9.

blockedby: =>
blocking: =>
priority: minor => critical

Fields changed

feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Fields changed

milestone: SSSD Deferred => NEEDS_TRIAGE
proposed_priority: => Core

As per discussion on 15.8. I can confirm that the concept of "preferred" ldap servers as per weight option in the DNS SRV record in not sufficient in this case as all servers have the same priority, but belongs to a different site.

What happens now is that sssd pickup the first ldap server which might be on a different site and hence available over slow VPN link only.

SSSD should implement something like "DC locator" functionality already found in the Samba code (see my comment above) to guess the valid DNS site first and use it to bind to the nearest LDAP server. If none available, we might even stay disconnected or attempt to bind a server on different site - this should be perhaps configurable.

Petr, is this something the planned DNS views feature would help with?

cc: => pspacek

Jakub, it is :-)

It will allow to return different DNS records for each subnet/querier's IP address. As a result you can return DNS SRV records with modified prioties and/or weights for each site.

Unfortunatelly, support for DNS views will be a quite big change in IPA and bind-dyndb-ldap. I can't predict real timeline for implementation.

I would not go down this route (if I can ask) as guessing based on subnets or IPs can be dangerous and unreliable. What I would really like to see here is something similar or the same as concept of DNS sites known from Active Directory - see for example http://technet.microsoft.com/es-es/library/cc759550%28v=ws.10%29.aspx
As I said this needs implementing something like DC locator functionality. I am sure Simo Sorce would explain more (please add him to comment). I must say I like this concept.

This link is probably somewhat better explains the DC locator:
http://premglitz.wordpress.com/2012/04/01/dc-locator-process-in-w2k-w2k3r2-and-w2k8/

Thanks for you comments! We need your feedback.

I'm not AD geek, please correct me if I'm wrong:

I looked into MS docs and, if I understood correctly, "sites" are defined on IP address basics for client machines.

See "Defining sites using subnets" in "Sites overview" from MS: http://technet.microsoft.com/en-us/library/cc782048%28v=ws.10%29.aspx

Also, from the link you posted: http://technet.microsoft.com/es-es/library/cc759550%28v=ws.10%29.aspx
Section "Domain Controller Location in the Closest Site" says:
"... For example, a portable computer that was moved to a new location could contact a domain controller in its home site, which is not the site to which the computer is currently connected. In this situation, the domain controller looks up the client site on the basis of the client IP address by comparing the address to the sites that are identified in Active Directory, and then returns the name of the site that is closest to the client. ..."

Pure DNS solution is universal, so each service can use it (as plain Kerberos and LDAP clients and so on). SSSD will not be necessary (generally).

Also, we can use some combination of both approaches. E.g. return records with priorities modified (selected by querier's IP address) and export all "sites" through DNS in similar way as AD does it. This approach should allow quick deployment for well-IP-partitioned configurations and manual setting for other situations.

Please, continue with ideas and cons of this approach!

I think you are right here. Every AD Site is assigned some set of IP subnets which reflects the actual physical location. In a nutshell it works as follows:

• Client compares its own IP address with the set of (by admin already pre-defined) set of subnets thus discovering to which site it belongs.
• Performs DNS lookup in form of _ldap._tcp.<SITE>._sites.<DOMAIN> to obtain a set of ldap servers valid for the site given
• Attempt to bind to the list obtained above using the weight factor saved in the SRV record.

This is very simplified view of the actual process. In reality it is bit more complex as every client has to obtain the "sites" definition in the first place. But this is the task for the "DC locator" mentioned above.

But I am no AD geek either so that's why I recommend we add Simo (or someone from the Samba team) to the CC list as they could explain it bit more deeper & advise which code can be re-used here.

Fields changed

milestone: NEEDS_TRIAGE => Temp milestone

Proper site discovery in AD domains involves using CLDAP as well. AS that's what tells you what site you should really hook up to normally.

I think we should create a pluggable discovery infrastructure, by creating the 'name' provider. Then turn the current stuff into the 'default' name provider. In AD we will instead by default use the AD name provider which will use AD sites. For IPA we will use the IPA Location discovery provider.

Fields changed

summary: RFE: sssd should support DNS sites => [RFE] sssd should support DNS sites

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

design: =>
design_review: => 0
fedora_test_page: =>
selected: => May

Fields changed

priority: critical => major

Fields changed

owner: somebody => pbrezina

Pavel, before implementing the AD discovery itself, you would also need to convert the SRV discovery into a plugin of its own, special-case IPA with the hostname discovery (Petr Spacek can help with setting up the environment) and then finally the AD specific site discovery.

Unit tests would also be nice, this interface is quite isolated, so it should't be too much trouble to mock them.

The desing was done by Sumit and reviewed on the sssd-devel mailing list:
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013553.html

design: => https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites
design_review: 0 => 1

Fields changed

review: => 0

First round of patches landed in master:

• 88275cc
• 1abdf56
• e26a019
• c65f009
• 77d165f
• f9961e5
• 673d4c1
• ca26179

Fields changed

status: new => assigned

Fields changed

patch: 0 => 1

The second wave of patches has been pushed to master:

• 4e748c2
• a679f01
• 5cc0b4e
• 05c53cf
• e653ff7
• 9894b0f
• 1099620

resolution: => fixed
status: assigned => closed

Fields changed

changelog: => In larger Active Directory environments there is typically more than one domain controller. Some of them are used for redundancy, others to build different administrative domains. But in environments with multiple physical locations each location often has at least one local domain controller to reduce latency and network load between the locations. Now clients have to find the local or nearest domain controller. For this the concept of sites was introduce where each physical location can be seen as an individual site with a unique name. The naming scheme for DNS service records was extended so that clients can first try to find the needed service in the local site and can fall back to look in the whole domain if there is no local service available. Additionally clients have to find out about which site they belong to. This must be done dynamically because clients might move from one location to a different one on regular basis (roaming users). For this a special LDAP request, the (C)LDAP ping, was introduced.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2074

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.