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, that would be unset in the vast majority of deployments.
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, 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.
bye, Sumit
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, 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?
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, 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?
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 (tm).
On Mon, 2013-05-06 at 10:18 +0200, Jakub Hrozek wrote:
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, 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?
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 (tm).
Yes we want SSSD just works, that is why I do not like your patch,. it makes it easy to break stuff and it is one more thing to add manually (and that is not how just-works works).
As for discovery: we can list the domains we have configured. Add a call to get the short name from the domain after it is initialized and backfill the flat name, store the flat name in sysdb so we can pre-fill it all the time except the first time.
Simo.
On Mon, May 06, 2013 at 08:52:51AM -0400, Simo Sorce wrote:
On Mon, 2013-05-06 at 10:18 +0200, Jakub Hrozek wrote:
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, 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?
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 (tm).
Yes we want SSSD just works, that is why I do not like your patch,. it makes it easy to break stuff and it is one more thing to add manually (and that is not how just-works works).
As for discovery: we can list the domains we have configured. Add a call to get the short name from the domain after it is initialized and backfill the flat name, store the flat name in sysdb so we can pre-fill it all the time except the first time.
That's what Sumit's patch will be about. This patch will likely be dropped.
On Mon, May 06, 2013 at 03:05:08PM +0200, Jakub Hrozek wrote:
On Mon, May 06, 2013 at 08:52:51AM -0400, Simo Sorce wrote:
On Mon, 2013-05-06 at 10:18 +0200, Jakub Hrozek wrote:
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, 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?
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 (tm).
Yes we want SSSD just works, that is why I do not like your patch,. it makes it easy to break stuff and it is one more thing to add manually (and that is not how just-works works).
As for discovery: we can list the domains we have configured. Add a call to get the short name from the domain after it is initialized and backfill the flat name, store the flat name in sysdb so we can pre-fill it all the time except the first time.
That's what Sumit's patch will be about. This patch will likely be dropped.
This patch is retired in favor of Sumit's "AD: read flat name and SID of the AD domain" and I'll mark it as "Rejected" in patchwork. If we ever feel we need an option, we can resurrect it.
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, 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?
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.
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Sun, 2013-05-05 at 23:21 +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, that would be unset in the vast majority of deployments.
TBH I am not really happy with doing this through a paramter.
A flat name is fully discoverable from AD and allowing users to set it has the consequences that they can get it wrong, and it is one more step.
What is the reason we want to have it so badly now, but do not want to do proper discovery to get it ?
Simo.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Simo Sorce -
Sumit Bose