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?
yes, if the responder cannot find a domain name it checks if the backend
provides a subdomain lookup. In the IPA provider the subdomain lookup
also extends the information about the local domain, at startup only the
fully-qualified domain name is known. I plan to do the same for the AD
provider, only that at the moment only the data of the configured domain
is read. Trusted domains can be added later.
sssd-devel mailing list