On Mon, May 06, 2013 at 10:14:01AM +0200, Jakub Hrozek wrote:
On Mon, May 06, 2013 at 09:40:21AM +0200, Sumit Bose wrote:
> On Sun, May 05, 2013 at 11:21:19PM +0200, Jakub Hrozek wrote:
> > Hi,
> > the attached patch implements the changes described in #1468. The logic
> > itself is implemented in confdb_get_domain_internal, which breaks the
> > layering a little because there is some knowledge about the providers
> > used in the responders, in particular loading the flat name is only
> > called if the id_provider equals "AD".
> > Also technically the NetBIOS name could be completely different from the
> > AD domain name and could have been read from the rootDSE. But honestly
> > I really don't think it's worth it, so I went with a config option,
> > would be unset in the vast majority of deployments.
> Since I need the SID of the AD domain, e.g. to properly evaluate the
> data in the PAC, I'm working on a patch which tires to read the SID and
> the flat name from AD. I'll try to send it to the list later today.
> I think in general it shouldn't be a problem to have both, config option
> and dynamic discovery. I only wonder how to handle the case of
> conflicts, i.e. the configured and discovered value differs.
But wouldn't there be kind of a chicken-and-egg problem? The responder
would need to know the flatname in order to send the request to the
correct domain while at the same time you don't know which domain to
send the request to. Or did you plan a similar concept as subdomains?
About the conflict -- in general I think that any locally set options
should override autodiscovery. But if the autodiscovery worked, would
there be a point in the config option at all? I would like to prevent
more and more config options for every aspect, the SSSD should Just Work