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:
> 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, that
> 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?